Manage workloads and resources across multiple clouds with IBM Cloud Automation Manager
An approach to deploy your cloud infrastructure on a hybrid cloud management platform
As you move more of your applications into the cloud, you have a greater need for appropriate management functions to accommodate them. What's more, your workloads are likely to run in multiple clouds that are served by different providers. However, for various technical and non-technical reasons, you cannot move all your applications into the cloud. Enter the hybrid cloud management platform. On this platform, you can manage workloads and their underlying resources across multiple clouds, including private and public clouds.
This article describes an approach toward a hybrid cloud management platform, by using the IBM® Cloud Automation Manager offering. It highlights the features of this service on Bluemix and includes a demo video so you can see it in action.
Cloud-enabled versus cloud-native applications
Most applications that are in use today were not built with the cloud in mind. Many were based on rather monolithic, multitier architectures that used middleware, such as application servers and relational databases. Yet, some cloud computing principles can apply to these workloads. For example, you can automate the provisioning and configuration of infrastructure and software in support of dynamic allocation of required resources, which is a cloud computing characteristic. As a result, these environments are called cloud-enabled environments.
At the same time, new applications are now developed with the cloud in mind. That is, they are based on more recently emerged architectural principles, such as a microservices-based architecture, and are built as 12-factor applications. These applications, which are called cloud-native applications, typically run in containerized runtime environments.
A hybrid cloud management platform must be able to support both cloud-enabled and cloud-native styles of workloads.
A brief description of the hybrid cloud
Much has been written about hybrid cloud. For the purposes of this article, consider this brief explanation. The coexistence of cloud-enabled and cloud-native workloads drives the need for hybrid cloud. For example, cloud-native applications that run on a public cloud provider might have to connect to an on-premises, cloud-enabled system to retrieve data from it that must be kept local for compliance reasons. Or, a company might move cloud-enabled and cloud-native applications to one cloud provider as a standard, but wants to also use certain cloud services that are available only on another provider's cloud.
The hybrid cloud is an environment that spans multiple locations, from existing on-premises data centers to private, dedicated, and public clouds that run in a cloud provider's data center. This environment hosts several connected workloads, which might or might not be built for the cloud.
This complex environment requires a central management platform—the hybrid cloud management platform. The rest of this article examines the various use cases that can help to identify the functional components that this platform requires.
Entry points to hybrid cloud management
Every enterprise has its own priorities and challenges to overcome. Each one approaches the creation of a hybrid cloud from various entry points.
The IT automation entry point is triggered by an IT organization's need to run its applications in a more efficient way. It focuses on the lifecycle management automation of all resources that are involved in running the application.
You can use templates to define abstract descriptions of topologies and environments. That is, you represent the application as an orchestration of resources. These resources are captured in a well-defined format and paired with an engine that can interpret and execute the orchestration. Resource types can be concrete and specific, such as a virtual machine, container, or network. They can also be more high-level and complex, such as a cloud service or an enterprise monitoring system.
Multiple languages exist that serve this purpose. Some of them are specific to one cloud, for example, CloudFormation for Amazon Web Services. OpenStack Heat is an example of a language that defines a set of generic resource types that are then mapped into existing resources by using the services that are included in OpenStack. Terraform is a language that uses provider plug-ins that define resource types that are specific to the respective provider.
A hybrid cloud management platform must be able to support multiple formats and their associated engines, and it must also support the deployment of templates across various on-premises and off-premises targets.
Not all resources are created and managed by using an orchestration in a template. Some resources were created before the management platform was established. Other resources were created natively by using the respective cloud tool. Therefore, you need a layer that can discover and manage these basic resources. Various libraries and frameworks that support this function currently exist, offering APIs across all relevant target clouds.
The following figure shows the architectural components that support this entry point.
IT as a service
For the IT as a service entry point, the goal of the IT organization is to become a service provider, at least internally, but often also with external consumers in mind. It requires a mechanism to exist for the definition of a blueprint that includes the basic units of automation (that is, the templates as described earlier). It also includes the integration of these elements into the larger IT ecosystem with third-party environments that are not part of the cloud and are not managed by the hybrid cloud management platform. For example, you might need to register a virtual machine that you created with a Configuration Management Database (CMDB). Or, you might need to update a firewall to access the newly created environment.
Moreover, enterprises need to establish a governance model around the use of IT services, which must be reflected in the management platform accordingly. In a simple example, this model includes the ability to define approval steps. In a more advanced case, it includes the ability to establish complex business workflows with, for example, human tasks and escalation processes.
A hybrid cloud management platform not only supports the initial provisioning and configuration of the relevant cloud resources, it provides appropriate end-to-end lifecycle management capabilities, too. For example, it provides simple control, such as starting and stopping individual resources. It must also allow customized definitions of Day 2 operations that might include manual tasks or other complex logic.
To directly support the separation of service providers and service consumers, a self-service portal is required that exposes IT services to their consumers in a controlled way. The service provider must have a way to define all the necessary elements of the service, namely an orchestration template, integration and process flows, and Day 2 operations. It must compose these elements into the final product, which is the service. This service can then be published to a catalog that is made available for consumers by using a self-service portal.
The following figure shows the architectural components that support this entry point.
A common driver for enterprises to introduce cloud computing is not just the need to run their IT operations more efficiently and with less cost. They also are looking for a way to quickly introduce new functions to their customers and to react to changes in market conditions. To achieve both objectives, they apply DevOps principles, which combine the development of applications with related operational aspects. One part of this concept is the allocation of a DevOps toolchain. This toolchain supports full automation of all parts of an application development lifecycle, by continuously testing, deploying, and monitoring and managing an application.
A hybrid cloud management platform must plug into a toolchain, such as the DevOps toolchain, in a way that maps the resources that it deploys and manages to the application workloads that run on top of them. Especially for cloud-enabled environments, creating the required infrastructure to host an application can be time-consuming. Also, its lifecycle is generally much longer than the application lifecycle.
Avoid placing the infrastructure orchestration and automation into the application deployment logic. For example, do not make it part of the automated build process or define it in an application deployment management tool, such as IBM UrbanCode Deploy. Instead, use the toolchain to delegate the infrastructure orchestration and automation to the hybrid cloud management platform by using well-defined APIs. With this approach, you can govern and maintain these environments, as described previously, while supporting automated and continuous delivery applications in production.
The following diagram shows UrbanCode Deploy and IBM Cloud Automation Manager working together as part of a DevOps toolchain.
Cognitive hybrid cloud management
Systems that offer automated provisioning and lifecycle management of IT environments have existed for some time. However, they typically do not support both cloud-enabled and cloud-native workloads in a hybrid world. But, they have the entry points that were described previously. A more recent development is the arrival of cognitive computing capabilities and the need to apply these capabilities to the context of hybrid cloud management.
The functional use cases for cognitive hybrid cloud management fit into two categories: human-computer interactions and cognitive operations.
The human-computer interactions use case describes ways of interacting with IT environments in human ways. That is, they do not entail a traditional user experience that is based on using a console or dashboard. Instead, these interactions involve conversation, natural language, or both. When this concept is applied to the hybrid cloud management platform, the user speaks or "chats" with the system about the necessary functions.
A concrete example is how a chatbot works in the way a conversation is simulated between a human and a computer program. Take the following dialog as an example of how a user, named Sandy, might interact with a chatbot, named Charlie, in front of a hybrid cloud management platform to compose and then publish a database service:
Sandy: Charlie, I want to let the finance team run MySQL.
Charlie: I found two templates that can create MySQL: "MySQL on VMWare" and "MySQL on Amazon."
Sandy: Let's try the VMWare one.
Charlie: I see you already have a VMWare connection called "Local Infra." Do you want to use that connection?
Sandy: Yes, please.
Charlie: The template has a parameter for Cluster, which has no default. You will need to specify a value for it.
Sandy: What are my VMWare clusters?
Charlie: You have "East" and "West."
Sandy: Let's use West.
Charlie: OK. Users will be able to specify "Required Storage." Is that OK?
Sandy: Let's limit that to 50 MB for now just so they can do dev test.
Charlie: OK. You don't have any Service yet so I created a new one for you. What would you like to call it?
Sandy: I want to call it "MySQLaaS."
Charlie: OK. You can test it by using this link or I can test deploy it for you.
Sandy: Test it for me please.
Charlie: I created one successfully with 50 MB. You can access it here.
Sandy: Looks good. Let's publish it.
Charlie: OK. Your service is now live. You can see it here.
Sandy: Excellent, heading home now.
Sandy: Good morning, Charlie.
Charlie: The finance team ordered two MySQL instances this morning. Both provisioned fine.
As another example, a speech-enabled interface can convert the spoken commands into API calls to the hybrid cloud management platform.
Cognitive cloud operations
In the cognitive cloud operations use case, we tend to use the term cognitive broadly, without consideration of its technical definition. For example, one rule of cognitive operations says: "If the data is structured, it's not cognitive. It's analytics." Some of the functions that are mentioned in this section apply machine learning, which is not cognitive.
All functional elements in the cognitive cloud operations lifecycle contribute to the ultimate result and are often, if not always, required to achieve that intended function. When you put them together, you can view the related functions in a cycle, as shown in the following figure.
These functions work with each other. The later lifecycle stages depend on the earlier stages to support a phased approach toward adding the function to the platform.
To enable any cognitive operational function, you need to collect structured and unstructured data from all environments that the hybrid cloud management platform interacts with. This data includes logs, alerts, and other events, in addition to explicitly pulled data about deployed resources.
Another source of data that can be used later for cognitive function is the collective pool of information that is amassed across all users of the system. The system can be made "smarter" by having everyone contribute to the information that it learns from. A system that uses machine learning can derive meaningful conclusions only if it has enough data to learn from. Therefore, you might think all hybrid cloud management platform instances should provide that data to a common place. However, this approach creates challenges around the use of potentially sensitive data that enterprises might not want to share.
By using the dashboard/reporting function, you can navigate, explore, sort, and filter the collected data in a simple way, by using various perspectives into the data, for example, geographical, organizational, or functional. Similarly, the system must allow creating custom reports of historical data.
When all the interesting data is available, you can analyze it by using the analysis/pattern detection function. This analysis can help, for example, to detect anomalies and error conditions or to determine trends and patterns. It can also apply machine learning to create models that feed into the next function, prediction, and response.
The prediction/automated response function is directly related to the previous stage. As soon as a pattern or trend is identified, you can predict how a system or workload is most likely to behave going forward. And, based on that prediction, in turn, you can define how you want the system to react.
For example, the memory utilization of an environment is detected to consistently increase over time, leading to the prediction that it will run out of memory at a predetermined time. As an automated reaction, the system can allocate more memory to that system.
In a more enhanced example, you can analyze the performance of several network resources across multiple cloud regions and then automatically move critical workloads to the environments that show the best performance.
The HCM Advisor function, which is the final element of the Cognitive Cloud Operations lifecycle, is where all other functions are used to make recommendations to the user. The advice can be applied at multiple levels:
- It can help create orchestrations and services that run better when they are deployed. For example, "You might want to define less vCPU for these VMs as a default because your application server deployments are historically under-utilized."
- It can help to guide service consumers at deployment time. For example, "The Dallas data center has sufficient capacity to allow for spikes in usage without the need for bursting into other data centers. Therefore, you should deploy your stress test environment there."
- It might be operational. For example, "You should scale out your messaging cluster in expectation of a seasonal peak in application load next weekend."
IBM Cloud Automation Manager
The foundation of the hybrid cloud management platform from IBM is the recent release of IBM Cloud Automation Manager. Ultimately, this offering will include the functions that are described in this article. The following figure illustrates the overall functional architecture of Cloud Automation Manager.
The first version of Cloud Automation Manager is available as a service in IBM Bluemix. It supports the deployment of the cloud infrastructure with template-driven automation based on the Terraform open source tool. It supports various prebuilt content and comes with a full set of APIs that allow programmatic invocation and integration with existing DevOps toolchains. The following figure illustrates the service that is now available.
Over time, IBM will enhance this solution and grow it into a fully functional hybrid cloud management platform, including the ability to run it locally in your own data center.
Watch the video demo!
This article described the functional characteristics of a management platform. It highlighted the needs of establishing a hybrid cloud. In particular, it explained the supporting infrastructure for deployment and lifecycle management across multiple clouds, both on-premises and off-premises, for cloud-enabled and cloud-native workloads.
In the future, these platforms will include cognitive functions for human-computer interactions and cognitive cloud operations. The starting point for this solution is the IBM Cloud Automation Manager offering on Bluemix. In future releases, this solution will support all the functions that a hybrid cloud management platform requires.
- Introducing Cloud Automation Manager
- Cloud Automation Manager documentation
- A new tool to manage multicloud with speed and control
- Bluemix Developer Center