Cloud Application Lifecycle ManagementLeave a Comment
Enterprises typically have diverse application portfolios, which is why so many are turning to a hybrid cloud strategy. Some applications have variable workloads and low data sensitivity, making them natural fits for public clouds. Others have data that not everybody is comfortable having outside of a corporate firewall and steady state demand, making them better suited for private clouds.
Regardless of where an application lives, and even if that changes over time, all cloud applications go through a predictable lifecycle that, when optimized with a Cloud Management Platform (CMP), can deliver better value to an organization.
Why a CMP?
Most companies have a hybrid cloud strategy precisely because of that application portfolio diversity described above. A problem with such a strategy in a vacuum, though, is that it can then become difficult to bounce around among different cloud consoles gathering information about deployments. Enter a CMP, which provides a single pane of glass through which an administrator can view all clouds where application deployments might land.
Such tools typically provide governance so that an administrator can dictate who is allowed to deploy what applications where. Metering and billing are important concepts as well so that administrators can put up guiderails for individuals or teams so that they don’t deploy too many resources at once without approvals.
Gone, though, are the days where it takes three weeks and multiple trouble tickets to get a virtual machine (VM). CMPs provide end users with self-service, on-demand resource provisioning while giving administrators a degree of control. An important aspect of CMP functionality is managing the lifecycle of an individual application, which typically starts with the modeling process.
The process typically starts well before an application is deployed in some sort of modeling process. Someone with application knowledge—and in this context an “application” can be as simple as a VM with your favorite operating system on it or as complex as a 15-tier behemoth with multiple queuing systems—tells the CMP about what components are a part of an application and how those components interact with each other.
Here, as an example, we have a simple three-tier Web application with a local load balancer (HA Proxy), a Web server (Apache), and a database server (MySQL). Each of the components commonly has security, monitoring and other details mandated by a central IT governing authority built into them. That way, any application modeler cannot easily break company-accepted standards.
When completed, an application model is then ready for deployment. But first, some time must be spent determining where it runs most optimally.
Placement via Benchmarking
Some applications are going to have their deployment target clouds dictated by data sensitivity or workload variability as described at the beginning of this article. Others, though, will have flexibility and have their placements based on comparing both price and performance in different clouds. How can you figure out which cloud an application runs best on, and what does “best” even mean?
That’s where a CMP that offers benchmarking can be helpful. With an application model complete, it can be easy to deploy it multiple times with test data and execute load testing against it to see which cloud, and which instance types on which cloud, offer more throughput. For example:
Here, an application model similar to the one discussed in the previous section was deployed across three different public clouds with 2, 4, 8, and 16 (where available) instance types at each of the three tiers. On the Y-axis of this scatterplot we see the number of transactions per second each configuration could handle, and on the X-axis it’s approximate per hour cost. Mousing over each dot would reveal the instance types used in each, but even without that, you can see that as the cost goes up beyond the first two instance types on each cloud, there are no significant throughput gains.
This means that to choose beyond the 2 or 4 CPU instance types, for this specific application, is a waste of money, and a final decision can be made when weighing whether or not price or performance is most important given the business case at hand.
Deployment and Monitoring
With the application model in place and the results of the benchmarking known, a CMP might even enforce the deployment of the application to only the best cloud given the results of the last test. CMPs typically perform rudimentary monitoring for basic counters like CPU utilization but leave more sophisticated analysis to tools like App Dynamics, whose agents can be baked into the application model components for consistent usage.
Revisiting Placement and Migrating Applications
But wait, there’s more!
Public clouds constantly create new instance types, demand for a specific application may wane or grow, private clouds may become more cost-effective with the latest and greatest hardware, and business needs are constantly changing. In other words, the cloud an application is initially deployed on may not be the one it stays on forever. Repeating the benchmarking exercise annually or quarterly is a good idea to detect when it might be time for a change.
Again, a good CMP should provide the tools to make it easy to back up data from the initial deployment, create a new deployment on a different cloud, restore the data to the new deployment and shut down the old deployment should a migration be necessary.
Managing applications in the cloud does not have to be complicated, and given how many aspects influencing an initial deployment choice change over time, application portability is important. Homegrown scripting tools used to manage these phases can grow out of control quickly or limit cloud choice to those a specific team has expertise with. Fortunately, CMPs make it easy to model, benchmark, deploy, monitor and migrate applications as they flow through their natural lifecycle.
This blog originally appeared on Cloud Computing Magazine.