It's becoming common to align a DevOps move with a transition to the cloud. The ability to leverage agile as a method is accelerated by the potential to deploy to private and public cloud platforms. The need for speed drives the movement to DevOps in the cloud, thus driving the need for the agility and speed that must be part of the development and operations process.
However, enterprises often stumble when moving to DevOps as a better path to cloud application development. The reason is the sheer amount of change that needs to occur, including people, processes, and technology. DevOps and cloud subject matter experts face a huge amount of work to transform organizations to make effective use of DevOps processes and technology.
Here's a 10-step process to help transform your organization to DevOps. We'll cover how to create and deploy an effective DevOps process as well as how to select the right tools.
Steps 1 and 2: Assess where you are and where you need to go
Start with an honest assessment of the current state of your processes, technology, and culture. For this process, I use a predefined maturity model (see Figure 1), which allows you a common gauge to rank existing people, processes, and technology within the organization. It's best that a third party perform this assessment, because self-assessments tend to be skewed toward the higher levels.
Level 1 (ad hoc) is where most organizations are today, so there's a great deal of work to be done. At this level, the organization is silo-based, typically uses blame as a way to get things done, has experts that don't share knowledge, and has almost no accountability. As far as technology, it does manual building and deployment, as well as manual testing. The development, testing, and deployment environments are inconsistent.
Level 5 (optimized) has a culture of continuous improvement. This includes zero downtime deployment, immutable infrastructure, and active focus on resiliency. Few organizations are at this point in the emergence of DevOps, although this is the objective. This is where you need to go if you're not there already.
Step 3: Define a DevOps organization
Defining a DevOps-oriented organization is perhaps the most significant step, but it's also the most difficult. Many organizations don't understand that this is a systemic change in personnel and processes. As such, if the organization doesn't add the skills needed, or if it becomes a more loosely defined organization, the project fails.
It's during this step that the organization needs to assess what it has in terms of skills. This skills assessment forms an understanding of the "as is" and the "to be" desired state, determines the existing gaps, and identifies the plans that will fill in those gaps.
Most envision layoffs as part of a reorganization around DevOps, but it's primarily a matter of retraining. After completing retraining, you need to figure out how each skill fits in with the emerging DevOps processes.
Some development organizations attempt to separate development and operations groups, but that route quickly becomes dysfunctional. A better approach is to combine them into a single role: a DevOps manager. As your development needs expand, increase the number of DevOps managers you have. This keeps organizations small, nimble, and focused on a specific purpose within the systems they build and operate.
Step 4: Define a DevOps process
There are many resources that tell you how to define a DevOps process, which is simply automated agile. However, there are as many types of DevOps processes as there are types of organizations, so you'll have to pick the one that best suits your needs.
Figure 2 shows a complete DevOps process you can use as a starting point. You may not need some of the steps, or you may have to add more. What should be consistent is your support for continuous development, integration, testing, deployment, and operations. The tools and the steps you use will vary based on your business and technology requirements.
.
This process typically spans traditional platforms, such as a Linux, Apache, MySQL, and PHP/Python/Perl (LAMP) stack, to newer public or private clouds. Figure 2 shows a typical demarcation line. However, the process can span all cloud platforms and cloud DevOps tools, or all traditional platform and on-premise DevOps tools.
Step 5: Define your target cloud platform
Defining the target platform for application hosting is important for two reasons. First, the target platform has a great deal to do with the DevOps tools you select, especially operational automation tools. Second, it further defines the DevOps process. Even though many say it shouldn't change around the platform, it does change. Needs for testing and deployment processes and automation change a lot between cloud platforms and even traditional platforms.
Selecting the right target cloud platform may mean selecting multiple platforms. Most DevOps processes I'm involved with use several public and private clouds. You may have OpenStack, AWS, Google, etc., and the desired target for the DevOps process may shift based on the applications and corresponding requirements. Or, at some future date, you may do least-cost cloud brokering to determine the cheapest and most efficient cloud on the fly.
Step 6: Select the tools for cloud and on-premise
DevOps tools aren't easy to understand. They use the same terms, but the types of functionality they provide are often confusing and overlapping. To address this, list your platforms and requirements, including how you're partitioning the DevOps processes between traditional platforms and the cloud.
Then compile a list of the categories of tools you'll need. Look again at this list at a higher level, such as continuous development, integration, testing, deployment, etc., and define the sub-patterns you'll need. Sub-patterns might include automated testing that is appropriate for the type of code and data you'll be employing. Finally, don't forget about operational tools that will ensure things are running properly.
Step 7: Define security and governance
Once again, these are systemic concepts. They're part of every step in the process. So, how do you define security and governance within the development process? How about testing and deployment? Also, and most importantly, how do you define operations?
This is the most neglected part of DevOps because it's one more thing to think about in an already complex set of processes and tools. However, it's important to figure out how to approach issues such as identity and access management (IAM) and how they fit into this process. What about data and service governance? How will APIs and services be tracked for dependencies? How do you select policies for data and service access? You must address all these issues.
Step 8: Test DevOps
This means exactly what it says: test the processes, tools, automation, skills, organization, and other components of DevOps by just doing DevOps. Flow a set of test applications through the process, and observe any fixes or improvements that need to be made.
You're likely to find many hiccups, which makes it important to note these issues and work on fixes as soon as possible, even though that could mean changes to your processes, skill mix, or automated tooling. This is new for most people who leverage DevOps approaches, and a long shakedown cruise is the only way to fix issues before you go live.
Step 9: Define monitoring and metrics
Look at productivity metrics and track overall performance with a focus on the value that's being delivered to the business. Make sure to track business agility and time-to-market in terms of value delivered. You'll find that if a DevOps process can compress the time it takes to release changes to a critical application from one month to one week, the value is often 30 times that of the DevOps investment.
By doing this, you're not trying to justify the existence of DevOps, although that's part of it. You're looking to understand where you're performing well—and not so well. By using metrics and analysis, you can determine code quality, integration issues, the number of testing errors that are occurring, and how well the system is meeting operational expectations. Using this data, you can add continuous improvement to the list of things that DevOps provides.
Step 10: Continuously improve
Finally, make sure you continuously improve your DevOps processes and automation tools. Work with a team of DevOps leaders and practitioners to constantly second-guess DevOps, always keeping an eye out for potential improvement areas.
DevOps in the cloud means improving operations by having an open and honest culture that craves change for the better and always looks at ways to provide faster time-to-production and better quality applications. This interactive approach to improvement is something traditional IT doesn't practice yet, but it's necessary if DevOps is to work effectively. Today, that's an imperative.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
