A bulletproof DevOps strategy to ensure success in the cloud
DevOps and cloud computing are linked. This fact is well understood by organizations that stand up SaaS clouds or build applications in the cloud.
The core component of this relationship is value through agility. DevOps provides the automation behind agile methods. Traditional target platforms require weeks or months of planning for the hardware and software required. Even with virtualization, the automated provisioning of those resources can’t typically be done on demand.
When it comes to implementing DevOps in concert with the cloud, there are a few core principles to understand and incorporate.
- There should be a continuous process that includes all aspects of development, testing, staging, deployment, and operations. There should be no time where parts of the process can’t be fully automated. This includes self- or auto-provisioning target platform resources.
- Major and minor changes to applications, from development to operations, should typically occur in less than one day. Moreover, the deployment platform should support almost unlimited provisioning of resources.
- The entire process can exist on premises, in the cloud, or in hybrid configurations. Moreover, the use of multiple cloud brands, such as AWS, Google, and Microsoft, should be supported, as well as public and private cloud models.
For organizations already practicing DevOps, the following steps will help guide them toward successful cloud adoption.
A DevOps strategy for success with the cloud
Here's how to extend your DevOps strategy to accommodate the cloud.
Step 1: Understand your own requirements
While this would seem to be a logical first step in moving to DevOps and the cloud, many enterprises often neglect the planning required.
First, you need to understand the solution patterns of the applications you’re looking to build. For instance, will there be data-intensive or processor-intensive applications, or a mix? Will the applications require any special hardware or software requirements, such as HPC or IPC middleware? Finally, consider security, performance, monitoring, governance — basically all of the core details that make up your requirements shopping list.
Keep in mind that you’re not looking to solve the problem of a single application, but selecting a core cloud architecture that can accommodate most of the applications that will be built, tested, and deployed using your DevOps automation solution. Also, keep in mind that it’s okay to use multiple target clouds for deployment. Indeed, multiple options for deployment allow you to define and redefine as clouds mature and the prices of public cloud services rise and fall.
Step 2: Define your DevOps process
What is the process that you want to employ, and for what end result? DevOps processes are very different from organization to organization. However, core to this is an understanding of how things are changing. Table 1 shows the old way of doing development and deployment versus the new way of using DevOps and the cloud.
Table 1: As DevOps and cloud become the primary way to build and deploy software, we must understand what's changed.
|The old way||The new way|
Software is build and shipped
Services are run and managed
Development of features is done
Services are never done until turned off
Product owners focus only on features
Product owners own operational results along with the product feature set
Each silo owns its own area
All groups focus on end user satisfaction
Dev must go through ops to get work done
Ops enables Dev to get work done
Ops monitors apps
Ops provides Dev with tools to operate apps
Reactive monitoring / Ops
Proactive monitoring / Dev
Customers are isolated from each other
Multi-tenancy and shared resources
Application services share common platform and infrastructure
Distributed services on isolated instances, hardware independence
Under the new way, for the most part, we are delivering not software, but services. In the old way, development had to go through operations to get any work done using the traditional model; but now, with DevOps and the cloud, Ops enables Dev to get work done. In the old way, there was reactive monitoring for operations, versus the newer proactive monitoring for DevOps and the cloud.
It’s important to understand which traditional approaches to development and operations to let go of as you move to DevOps and the cloud. In most instances, this means blowing up traditional waterfall methods and tools. Now we must figure out the least latent approach to the DevOps process, including consideration of the target platform, which will likely be private or public clouds. To break this process down further:
- Continuous development is the ability to build applications or services and, at the press of a button, have the solution tested, integrated, staged, deployed, and pushed into operations within the target cloud platform or choice. During any step in this automated process, the solution may be returned to the developer for correcting any problem found. This allows developers to operate near the speed of need, which is the ability to respond to business user requests in near real time.
- Continuous testing is an automated testing process that is coupled with continuous development, including unit and system tests that are automated for the applications as they move through the DevOps process. Testing can occur on premises or within public clouds.
- Continuous integration is a development practice that provides for the integration of code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early, and is also coupled with continuous testing and continuous development.
- Continuous deployment means that each change that passes the automated testing and integration procedures automatically moves to production. Public clouds are typically the target platform, which are able to accept integrated and tested code and keep it in sync with the rest of the DevOps processes, no matter where the automated tools exist.
Step 3: Select and test tools
The tools selected must work with public cloud services. In most instances, they also need to work with private cloud services so enterprises can deploy to a hybrid cloud. Thus, the cloud-enabled DevOps package needs an interface with the cloud provider's management system.
Next, you need to make sure the tools support network and IT resources because, in many instances, applications will be complex and distributed. This leads to the need to create and maintain network connections between the applications. In essence, clouds and cloud-based applications are all complex distributed systems.
Finally, you need to link the application and the DevOps tools with security, governance, and monitoring features of your target cloud platform. This means that you need to link into the security services of your cloud provider of choice, such as identity management services. Moreover, you must figure out approaches to service and resource governance, as well as monitoring and management of the links to your DevOps tools and applications, and to the services provided by the target cloud platform or platforms.
Step 4: Focus on automated testing
When working a DevOps strategy that will leverage public and private cloud platforms, the core focus needs to be on automated testing services. These services can live in public clouds and be provided by either the target public cloud platform or a third-party cloud provider. In some instances, they may be delivered from traditional on-premises systems.
Core to these automated testing services, you need:
- The ability to create automated test scripts that are coupled to applications. These tell the testing services how to test the applications, including what is considered passing, which allows the application to move to staging and deployment.
- The ability to provide test data for application testing. This is typically provided as a service by the cloud provider. This allows the application to leverage near true-to-life data that will reflect production-level loads, and it should find any issues before it passes down the line to deployment and production.
- The ability to test services that surround the application, including service governance, security services, and even monitoring services. Considering the importance of these services for applications that reside on cloud platforms, these should live up to expectations of the application, and thus need to be included in testing.
Step 5: Organizational change
DevOps is about people, perhaps more so than the tools and the technology. You need a plan to hire the right people to augment your staff as you move to DevOps and the cloud, as well as provide them with the right amount of training.
Create a plan that reveals the gaps between the skills you have right now in-house, and the skills that you’ll need. Naturally, your plan may lead to some minor adjustments in more innovative organizations, and to some major upheavals in others.
Organize around the use of DevOps in the cloud, which typically means removing layers of the organization and simplifying roles. For instance, you no longer separate the development and operations skills; they are tightly coupled and practitioners need to be good peers.
Step 6: Implementation
Now the hard part. You need to implement the DevOps tools and the cloud platforms. I recommend that you do this in stages, working from the Dev tools to the Ops tools, and then integrate with the target cloud platform.
It’s not "if" you’ll find issues that you’ll have to fix, it’s "when." Keep in mind that both DevOps and cloud computing are relatively new concepts, and so is the technology. You’ll have to allow time to solve many problems that will arise, but if you keep in mind the ultimate value, it’s well worth it.
It’s all about agility
The integration of DevOps and cloud is not just about building better software; it’s about bringing agility to the business. When thinking about the value of the marriage of DevOps and cloud, you should also think about the ability to quickly build and deploy software, and the ability to avoid waves of hardware and software purchases to run the applications. IT becomes the core value driver within the business, not just overhead.
The business value of these technologies is tremendous.