There are two growing trends in cloud computing right now: the use of DevOps, as both an approach and mechanism to build and deploy applications, and deployment of those applications to more than one provider or type of cloud services. That’s what most enterprises today are dealing with—multiple clouds.
Organizations that are driving a new DevOps strategy need to account for this multi-cloud application deployment. The DevOps tools you use must be able to reliably deploy code to private, public, and hybrid clouds, as well as different service providers, such as OpenStack, Amazon Web Services, Google, HPE, and the like.
DevOps strategies and tooling within these multi-cloud enterprises must account for the differences in platforms so that they can leverage the right native features without losing the automation and productivity of DevOps. These patterns will help you identify how to build cloud-specific automations in a DevOps pipeline.
Defining the problem and solution
There are several problems that need to be solved:
- First, the biggest challenge is the ability to deploy to multiple targets and take advantage of the native capabilities (cloud-native applications) with new, unfamiliar DevOps processes and tools.
- Second, the cloud target platforms are in a state of rapid change. DevOps tools need to dynamically adjust to those changes—in most cases, without human intervention.
- Finally, security and governance must be part of this process, and they are still very platform-specific. Thus, logging, tagging, and other cloud governance concepts need to be considered in the tools, the applications, and the target cloud platforms. This adds another layer of complexity to consider.
These challenges address the core requirements of a multi-cloud DevOps pipeline. DevOps engineers will need to look at the platform-specific requirements and how to automate testing and deployment. They’ll want to consider using platform-specific tools from each of the vendors. These tools can cover testing, deployment, continuous operations, and CloudOps.
Platform-specific testing for multi-cloud deployment
As you can see in Figure 1 below, the front end of the DevOps process seems pretty standard, and you can rearrange the core tasks to meet your needs. In multi-cloud deployments, it’s important to remember that you’re taking the same code set, typically coupled with data, and marking it for a target platform at the point of staging.
Next, the application runs through platform-specific testing (see Figure 1). This tool/process checks the application for issues that it may have when using some of the native features for each cloud platform. For example, provisioning is different from cloud to cloud, so this testing engine would look for provisioning issues that are either unaligned with best practices or mechanically incorrect (such as not leveraging a native API correctly). The engine would also look for other issues that would make the application not work on the target platform or, more likely, cause sub-optimal performance.
A good system should automate the correction of issues where it makes sense, and if they cannot be corrected, they should be returned to the developer for manual correction. Once that’s complete, the application needs to go through the platform-specific testing step again.
Figure 1: The DevOps process ends with platform-specific testing. This deployment step deals with more than one cloud vendor or type.
Monitoring and governance for multi-cloud deployment
Assuming that all of the platform-specific test findings are resolved, the application moves to the “deploy to production” step. Within this automated task, the application is packaged up for deployment to each target cloud platform. This means it’s placed on a machine instance within a private or public cloud and enters into a “continuous operations” process. This includes several components:
- Resource Governance (CMPs)
- Service Governance/Service Catalog
- Security (IAM)
The proper use of these components is key to the success of your multi-cloud DevOps automated solution. Once placed into production, the ability to effectively provide application and data services to the end users is really where the rubber meets the road, so let’s go over each component individually.
Monitoring refers to the ability to monitor the application during execution. This process looks at performance and stability issues, and includes setting thresholds for these subsystems. If the readings exceed these thresholds, the DevOps system is alerted as well as the CloudOps admins.
Management refers to the ability to manage the applications, or take action based on interpretation of the monitoring data. This means resource management, including using a CMP (cloud management platform), and the overall management of all major application components and subsystems, including security and governance, as discussed next.
Resource Governance refers to the use of a CMP or other similar tools. The idea is to abstract those who manage the cloud-based applications on the target platforms by using a single console to manage applications and resources from multiple clouds on a single cloud. This allows you to set user policies that span all of the clouds you have applications deployed on. These policies should also work well with the application-level security and governance of each cloud.
Service Governance refers to the ability to create policies around the use of APIs and services, and even the use of services between clouds. This means that we can create common services in any cloud and have those services leveraged by applications running on any cloud. Those services, either infrastructure- or application-level services, are tracked using the Service Catalog. As the name implies, it’s the repository for all of the services in your cloud(s) or on-premises systems. You can use remote services here as well, such as those spun up by purpose-built clouds.
Finally, cross-cloud Security is a huge issue to consider. In a multi-cloud model you do not want to deploy and manage too many different security services because that increases the complexity and the cost of deploying applications. In cloud environments, you’ll typically be dealing with identity and access management, which has the ability to track all applications, resources, services, data, humans, etc., and define access and authentication policies and rules for each.
Steps to successful multi-cloud deployment
Building multi-cloud deployments into your DevOps pipeline is not yet as straightforward as it should be. Why? All of the major processes and technology are still emerging around development and operations. However, there are four steps that can help you take advantage of DevOps-style multi-cloud deployments now.
- Align DevOps automation processes and tools with the platforms that will be in operation. I see many enterprises run a mixture of products and services from AWS, Microsoft, Google, HP, etc., because they do different things better, and at different levels of cost.
- Understand the details of the target clouds. What are the native features? What are the runtime environments? What are best practices for coding, data, etc.? I’ve found that these aspects are well documented by most cloud providers. They even document ways to leverage the target cloud from a DevOps environment. You will have to research this for every target cloud that your organization is using or wants to use.
- Define your DevOps processes with multi-cloud in mind. While some enterprises find it easy to connect different target cloud platforms, many DevOps processes require major re-engineering to get to a point where applications flow seamlessly back and forth from development to operations.
- Consider service-orientation as a core enabler. Keep in mind that you’ll be sharing services among applications and among cloud platforms. The end result is that you’ll have a single application that could run hundreds of remote services, from dozens of different clouds. This requires a great deal of services and resource tracking, including identity and access management and service governance. However, the business value is off the charts when considering developer productivity and the value that is returned to the business.
This is not easy stuff. However, cloud computing and DevOps can return the investment to your enterprise tenfold. It’s worth it for enterprises’ development and cloud organizations to at least consider the value of multi-cloud and how DevOps can be hooked into multi-cloud deployments.
As enterprises become better at using multi-cloud, and monitoring and management tools become better, this model will only become more compelling. But what drives this growth will be the ability to leverage the emerging DevOps automation practices with any target platform, including multi-cloud. “Automate everything” will be the battle cry of 2016 and the ultimate challenge that enterprises face going forward. Platform-specific testing, monitoring, governance, and security are good places to start.