The biggest challenge that IT organizations face today is to figure out the most optimal way to enable their businesses to be agile and build platforms and frameworks to deliver services to their customers in fast and efficient manner, without compromising quality; And all of this while their IT budgets are shrinking. IT has generally been under such budgetary pressures, but this decade is going to be very different because of the cloud, big data and mobile capabilities going main stream. Customers/Consumers are becoming impatient with longer wait times for getting faster and better services and if businesses don’t catch up and meet these accelerated expectations they run the risk of being disrupted.
Welcome to DevOps!!
Every organization, CIO and IT leader has been thinking about implementing DevOps within their organizations. Few of them started DevOps initiatives and others are figuring out where to start and how to make sense of DevOps within their complex environments. Regardless of whether you started a DevOps initiative or figuring out where to start and how to make progress, here is a checklist of things that are critical to ensure successful adoption of DevOps within an organization:
1) Define “WHY and WHAT” of DevOps: IT leaders shouldn’t just say “Let’s do DevOps” and delegate down. A clear understanding of what DevOps is specifically going to address for their business needs to be defined, goals & objectives need to be clearly captured and metrics to measure and track progress should be clearly ironed out early-on. A baseline needs to be established that will tell you where your organization is today in terms of the KPIs or metrics that you want to improve; Is it the cycle time for deploying a feature into production, is it release management efficiency, is it time taken to provision an entire application environment etc. Without this first step, the rest of the DevOps initiative can spiral out of control very quickly because not everyone may be on the same page.
2) Share the goals, metrics and progress with all teams involved: People involved in DevOps initiatives are typically developers, testers and operations folks. Most of the times the business value that DevOps initiatives actually provide are not shared down to the grass roots engineer levels. Engineers love technology and will play with the coolest toys, but it’s extremely important for everyone involved to understand why they are playing with coolest toys and building automation pipelines and the impact this game of DevOps is going to have on the business. Everyone needs to understand that IT is there to enable the business. Fill this out for your organization.
“DevOps is enabling my organization by ………………………………… “
(fill in the blanks as appropriate for your organization)
3) Every organization is unique and so are it’s DevOps goals: We have talked to many IT leaders (CIOs, VPs and IT managers) across various industries and sectors about DevOps and one very common statement/question that we heard people say (and especially those in highly regulatory sectors such as banking) is “I don’t need to do 10 or 50 or 100 deployments a day so I cannot do DevOps, or I cannot give any developer access to production environment, so DevOps probably doesn’t apply for me”. Wrong. DevOps is a way of building and maintaining quality software. Do what works for you but embrace automation.Continuous Delivery tends to measure # of deployments as a common metric but that number can vary from organization to organization. Automation that can reduce the provisioning times for application environments, pro-active monitoring and management of processes and systems, process for getting notifications and alerts in production to developers early-on etc are also goals that can improve overall application development and deployment process thereby reducing the cycle time. The bottom line is to pick the metics that are realistic for your organization. But definitely be a little aggressive to push the envelope.
4) Automation is the cornerstone of DevOps: Automate as much as possible. But do not automate before you standardize. Standardize your technologies and processes and have a good configuration management and change management process. We have seen people automate things that frequently change or those that are not standardized. Doing so creates a maintenance nightmare to keep track of all the non-standardized automated programs and scripts. So, it’s very important that you Standardize before you Automate.
Infrastructure, platform and environment provisioning should be automated. Cloud is an absolute accelerator for Infrastructure provisioning. Implement continuous integration, automate your testing processes as much as possible, and implement push button deployments for promoting code into various environments. These are just some of the things that can be automated.
5) Emphasize and support Quality Assurance early-on: Based on what we have seen, in general QA gets the least amount of time to do quality assurance and eventually the quality of the product suffers. Because automating the deployment pipeline is a goal in DevOps, it becomes even more critical that QA gets enough time early on during DevOps initiatives to write automated tests suites for regression, functional, non-functional, acceptance, smoke and all other kinds of testing scenarios. Keep in mind there many be times when you have to some manual testing to ensure product quality and that is totally acceptable. Just because everything is automated doesn’t mean everything will be right. Doing the wrong things the right way will cause more problems in the future than doing the right things the wrong way. So make sure your QA teams are involved along the way and part of the automation journey.
6) Everything is code — Think Infrastructure-as-Code, Environment-as-Code: Because automation is the cornerstone of DevOps, every entity (infrastructure, platform, environment, application, process) now should be defined by writing code. Hence a good configuration management strategy is extremely important. If something is broken during a process of deployment or provisioning or testing, don’t hack and fix it for that one instance. Stop the process, fix the automation script and re-initiate the process.
6.1) Eliminate Configuration Drift: It is important to have identical configurations in Dev, Test, UAT and Production environments (and DR environments as well). Have processes in place that will check for configuration drifts. Most of the configuration drifts happen when people tend to hack the system instead of fixing the issue in the source and restarting the process. Having an efficient provisioning and configuration management strategy is key to eliminating configuration drifts.
7) Common Frames of References for Dev, QA and Ops: Application developers having access to production environments is a loosely used argument in DevOps and is debatable. Not every organization can/will do that (because of regulations, compliance, policies etc.). But what every organization should be able to do is provide common frames of references for application performance monitoring in production environments. A developer should see the same screen that the Ops person is seeing about how the application that the developer built is performing in a live production environment. Also create a common frame of reference for viewing production logs. This will be especially useful in distributed environments where transactions span multiple nodes and if logs can be consolidated (using various log management tools such as log stash, kibana, elastic search or splunk) and viewed by relevant people it will help speed up and drive analysis of any issues that arise.
Dev and Ops looking at the same thing through a common frame of reference is what we want to achieve in DevOps.
8) Cloud as the Accelerator for DevOps: Yes, everything can be automated but leverage the power of cloud to automate infrastructure and platform provisioning as much as possible. As container technologies such as Docker become more mature, they are certainly going to play a big role in how development and deployment pipelines are created and executed. Most clouds are going to have support for container technologies so it will be a natural extension at that point for extending your architecture from cloud VMs to cloud containers.
- Start Small and Continuously Improve: Don’t go bing bang with any enterprise initiative and the same applies to DevOps. Identify a pilot application, create the required deployment pipeline via. automation by bringing together concepts such as rapid environment provisioning, continuous integration, push button deployments and code promotion, automated testing (as much as possible), monitoring and management and application life cycle management. Go through few quick iterations to build confidence into the new framework and after the pilot is successful, take it to other applications and teams. Always measure against the defined business metrics and capture lessons learned to continuously improve and push the envelope. DevOps is a way of doing things. Make sure that the people involved initially are influencers and can take the principles back to their respective teams.
- Capture your Response Procedures for Worst Case Scenarios: What we have seen organizations do when they start DevOps initiatives is always talk about best case scenarios. Starting a green field application and taking the code from Dev through QA through Prod along a fully automated pipeline sounds great. But don’t discount the scenarios where something is broken in production during your peak business hours. The question is what does your process look like to get that notification, identify causal factors, pass it on to developers if ops cannot fix it, collaborate real-time with everyone involved (what tools and how is collaboration done), provisioning that application environment in minutes (as developers and testers now probably are working on a newer version), run your end-to-end test suites to ensure the defect is fixed and nothing else is broken along the way and then deploying to production.
Have fun building your automation pipelines and software manufacturing units. Initiative such as DevOps bring in a lot of cultural change as well and change across people, process and culture needs to be given a serious thought as well. And always keep in mind we are doing this so IT can enable the business so you can serve your customers efficiently.