DevOps Models

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.