Are they the seeds to be nurtured to bring in automation, innovation and transformation. There is a saying, necessity is the mother of invention. I would say, innovation is amalgamation of creativity and necessity. We need to understand the ecosystem, to apply creativity and identify the ideas to bring in change. We need to be competent with changing ecosystem and think beyond the possible. What is the biggest challenge in doing this? "Unlearning and Learning", we think the current ecosystem is the best. Be it health, finserve, agriculture or mechanical domain, we need to emphasize with the stakeholders, to come up with the strategy to drive. The very evident example here is the quality of life is changing every millisecond. Few decades back the phone connection was limited to few, but today all the millennials are having a mobile phone. Now phone is not just a medium to talk, but are so powerful devices that an innovative solution can be developed on it.
Hello Everyone,
IT industry is going through a Disruptive
Evolution, where Artificial Intelligence and Intelligent Automation is helping
organization go Lean and Agile. Leaders are at the crossroad where they need to
pick the path which will empower their business teams to be more productive and
focus on core. In this blog, I tried to invoke a thought process for leaders
how they can step up their game by taking baby steps but still following fast lane
to reach destination on time. Thought leaders must have been tracking the
industry pulse how IT is changing fast pace by adopting Artificial Intelligent Driven
Innovative frameworks. To drive Delivery in much more efficient and eloquent
way, everyone must adopt new optimized Development and Operations practices to
sustain in the current competitive ecosystem (Service or Captive world), by
keeping cost to minimal.
IT gurus are smartly redefining their vision and
practices towards Lean methodologies. DevOps is coined to shave off cost by brining
synergies between both Development and Operation blocks. Historically, both
entities had worked in isolation but with DevOps adoption they are synergizing
and reforming to act as a single entity. Smart organization are managed to mold
themselves to a single team culture, which will manage both Development and
Operation tasks briskly. With this context in mind, let us talk “What is DevOps and Why do we really need it”?
By no means, DevOps a new topic, it practice has been discussed over decades as
Patterns and Practices or sometimes as Delivery Automation. After incubating
DevOps for different clients, I concluded that DevOps is not about handshaking
between Development team and Operations team using various technology stacks
but much more than that. Is it “An old wine in a new bottle?”, I would say
“YES” but packaged well with new features.
As a DevOps consultant, I realized everyone has
their own definition of DevOps. I did not find any definition to be wrong but
each definition reflects the maturity of DevOps practice by each entity. One
was maturity level of each implementation was different and another key aspect
which was highlighted was what each entity was trying to achieve was very
different. Let me answer few questions before we progress on this topic, consider
them to be myth busters.
Is DevOps
limited to Development and Operations? No, it is much more than (Development) Dev and
(Operations) Ops.
Can we implement DevOps in isolation? No, DevOps goes hand in hand based on project methodology. Approach and DevOps stack various if approach is Agile and/or Waterfall.
Is DevOps all about implementing tools? No, it is much more than implementing tools, it covers tools, Processes, Methodology and other softer aspects like people maturity and demographics. How all these contribute to decide on DevOps practices, we will cover in details sometime later but will still touch upon it in this blog itself.
Do we have to execute across all areas to be successful? No, it can be implemented in a specific area based on the business need and focus area.
If DevOps is not about tools, then what is it?
DevOps journey revolves around People, Process, Tools, Maturity, Methodology,
Culture and the Problem statement.
People and
Stakeholders: Understanding and willingness to accept new ways of doing
things. Acceptability and openness to implement new techniques is the key. Stakeholders
should be willing to go for major change and people in the organizations willingness
to embrace changes is important to decide on level of DevOps practices. Taking
baby steps and grow bigger over time is the key for success.
Process
& Methodology: Why I listed processes and methodology together is
because they go hand in hand. It makes sense to look at these aspects in composed
manner rather than in seclusion. Changes are inevitable and processes are also
changing much faster pace because of disruptive technologies. Keep in view the level
of flexibility of stakeholders to fine tune processes using DevOps fundamental,
need much more detailed evaluation. There is NO need to move jump on to Agile bandwagon
just to implement it. DevOps help become more productive if both process and
methodologies are fine tuned to complement each other.
Architecture:
Why do we have to really talk about Architecture or Technology, it is because
older technology stack might have limitations or not worth tweaking to adopting
because of low ROI? Older technologies
like VB5 or VB6, is it worth implementing DevOps or migrating them to new
technologies, need assessment to get right answers. There are tools and
technologies to get on DevOps with legacy stack hence question is about evaluating
the right approach based on assessment.
Tools:
There are plenty of tools which exist in market to pick from, which tool is
right for an entity depends on the current tools\stack implemented in current
state. Like if project is using .NET technology then tools like VSTS and SQL
server must already be in use for development, going for Azure cloud make sense
where as if someone had open source stack like LAMP (Linux, Apache, MySQL, PHP)
going for mix of open source and purchased tool stack like GitHub, Jenkins,
Maven, SonarQube make perfect sense. Picking up right tool will help get ROI
much faster.
It is a time for entities to now focus on Inner
shell which defines what type of DevOps to pick up.
There are different DevOps Maturity models, in this blog we will cover
few but these are not the exhaustive models, there could be many more. We will
focus separately on Dev and Ops section of DevOps framework. There are
different school of thoughts and many experts consider it to one but my thought
process suggest they are different. Objectives and Outcomes are very different
for each model.
Let me help you comprehend key principles of Dev of DevOps in this section, where focus will
be on how Development stream can make transformation.
Dev - Automating Development\Build phase: In this model Build phase is fully automated.
Each tool complemented each other to make sure Developers are productive and
quality of the product is excellent, by trapping defects early on in software
cycle. This is also called Continuous Development. This covers Integration
of source control for check-in code, Auto code review, Auto Build, Automated
unit test case execution and automated build (Code compile and binaries
build).
Dev - Automating Test\QA phase: In this model, QA tasks are fully automated
hence Test Execution effort is minimal to Zero. Zero Test execution can be
achieved by adopting Development Driven Testing, Design Driven Testing,
Behavioral development testing and Test Driven Development QA approaches. There
are enormous set of QA tools such as Selenium, HPQC, JBehave, TOSCA and many
more such frameworks can be leveraged. This is also called Continuous Testing. Developers will be the testers of their code
as most of the developers will write the automated test cases to test their own
build bits.
Dev - Automated Build and Test: In this model,
Developers and testers are integrated well to handle churning out the quality
build quickly. It is also called Continuous Integration. Build quality from Continuous Integration is
much better, it helps achieve Speed, Scale and Consistency. CI helped save
team’s time and rework effort by catching defects early on while developers are
still on job. During whole CI practice code is continuously getting merged into
a central repository post which it kicks of Automated build and Automated
Testing in sequential order. With effective CI developers, can deliver build
more frequently to an extent of few build per minute(s).
Here is a list of few tools to setup robust and flexible Continuous
Integration framework:
·
Continuous Integration tools (i.e., Jenkins,
Cruise Control, Bamboo, Team city…) · Source control tools (i.e., GitHub, CVS, VSTS etc.),
· Build tools (i.e., MsBuild, Maven, Grunt, Rake...),
· Code Review Tool (Gerrit, SonarQube, Crucible...),
· Build Generation tools (i.e., Meson, Premake...),
· Automated Testing Tools (i.e., Selenium, Cucumber, HP Win Runner, TOSCA…)
With CI, following steps are automated:
·
Check-in code to Code Repository.· Auto code Review (before or after code check-in)
· Build automation.
· Automation testing.
“Continuous Integration is a software development practice where members
of a team integrate their work frequently. Each person integrates at least
daily - leading to multiple integrations per day. Each integration is verified
by an automated build (including test) to detect integration errors as quickly
as possible. Many teams find that this approach leads to significantly reduced
integration problems and allows a team to develop cohesive software more
rapidly” Martin Fowler Chief Scientist, ThoughtWorks
Dev - Automated Build, Test and Pre-Prod Deployment:
This is Continuous
Delivery, which take continuous Integration to next level by
plugging in auto release component to CI. If we add another automated step of
deploying successfully tested build bits to Pre-prod it is defined as Continuous
Delivery. Continuous Delivery help organization go lean. Continuous Delivery
help gather early feedback from customer by deploying on Pre-prod on regular
basis. Key principles of Continuous Delivery are:
· We should crate build only once and deploy
across various environments (QA, Pre-Prod).· Test successful Build Compilation, Completion, Testing and Deployment.
· Successful build assembly line on single click.
Tool stack and framework remains same as in CI but tools are
configured to do auto deployment to Pre-prod. Continuous Delivery guarantees
readiness of quality deployable product by deploying all components on
production like environment.
Dev - Continuous Deployment (CD): Automation
of E2E process across software cycle from code to Production deployment is called
Continuous Deployment. CD play a key role in reducing time to market and make
sure customer needs are taken care with utmost urgency. Once we have successful
Continuous Delivery, plugging in a new switch to make it single click
deployable on production is CD. Continuous Deployment stops at deployment
to production, may be if needed sanity testing is performed by users or team
manually. With this switch, release teams had really gone thin in terms of team
size yet less error prone deployment is expected to be completed on Time.
Whatever DevOps principal we had discussed till now are pretty much
applicable to Development side of DevOps. There are many more Dev of DevOps
principle which I will cover later once Ops of DevOps are understood. Operations mindset is
very different and it is this which keep lights on for the deployed product in
production. Every aspect of Ops of DevOps contributes towards the degree of Pro-activeness
and Operation Excellence Maturity level.
Ops – Continuous Synthetic Testing: What is
synthetic testing? Executing test cases using dummy data to cover key journeys
E2E from end customer perspective on Production environment. In case any issue
or incidents detected while executing synthetic test cases they were reported
back into the defect tracking tools manually or automated using APIs. Why
synthetic Transaction are important is a different topic which I will keep it
aside for this blogs discussion. Continuous
Synthetic Testing helps operation team achieve following
objectives:
·
Product System Stability i.e., there is no
bug/issue. · Product Performance Metrics i.e., product is running as expected with no slowness glitches.
What is important for DevOps team is to consider building synthetic test cases and deploying those test cases in production, by leveraging synthetic lean test framework. This will help operations team measure product stability as soon as Continuous Deployment hits production.
Ops – Continuous Cataloging Operations: What is Cataloguing
Operations? Creating a catalogue of issues behind the code on production
environment by enabling logging. Enabling products to alert operations team and
Resolve and issue based on in built Machine Learning/Artificial Intelligence is
called Continuous
Cataloging
Operations. In legacy work environment instrumentation was part
of Product design but with disruptive IT there is a need to change design
principals to not just enable product instrumentation but enabling product to
have Machine Learning capability and thus act smart based on Artificial
Intelligence.
What is important
for DevOps team is to change the design principals upfront and embed Cataloging
and Machine learning capability in product to make them self-sufficient. This
robotic capability will enable organization to go lean on operation and focus
on new feature development meeting customer business needs.
Ops – Continuous Monitoring Operations: Continuous Monitoring
Operations is a very important task for operations team.
Operations team’s maturity in leveraging tools like New Relic, Splunk, ELK
stack and Solar winds is continuously increasing. Enabling operations team to
pro-actively handle issues make entities gain operational excellence. This is a
continuous feedback or loop mechanism to harvest learnings on regular basis. With
continuous deployment, monitoring plugging should also be updated to start
capturing Application Performance.
Ops – Continuous Delivery Pipeline: Continuous
Delivery Pipeline is the key concept to make DevOps team focus
on Product Development. In parallel Business Analysts help prioritize and
tradeoff work items from common Product backlog of product defects and new
features for the existing product in production.
DevOps is a power way of aligning teams, processes, tool and
methodologies to gain synergies by implementing lean concept to manage
Development and Operations.
DevOps is not about implementing tool and changing processes it would
need thought leadership push for a structural change in culture. Cultural
change should enable organization to balance prioritize Business requirement,
Development requests and operation needs. All these changes will lead to enrich
outcomes listed below:
·
Increase successful deployments· Increase in deployment frequency.
· Faster time to Market
· Stable product.
· Reduced mean time to resolve an issue.
· Higher stability and availability of product.
· Artificial Intelligence drive operational Excellence.
I hope this blog was helpful and enable new thought process DevOps is
not limited to Continuous Integration, continuous Delivery and Continuous Deployment
but continuous Operations as well. It is a mindset change for people and
leadership team by adopting disruptive Operation techniques. I will get back
with another set of blog covering each aspect of DevOps in detail. Till then
stay tuned and Happy DevOps.
Comments
Post a Comment