Creating application images, using entire virtual machines or otherwise such as container-based, is a convenient way of “snapshotting” applications, allowing them to be able to seamlessly move such images from one infrastructure to another—including virtualized clouds. Today, there are a growing number of various image-based tools available that do, in fact, make it easy to “convert” from one virtualization format to another, offering the efficient portability of images across different infrastructures – including clouds. Regrettably however, most are quickly finding that moving an image is only part of the challenge in enabling an application on a cloud environment. Getting these images to actually work optimally, connect with each other and other resources while maintaining portability once on the target environment/cloud…is a real problem and one that is not addressed by this class of solution.
WHY IMAGES ARE CONSIDERED USEFUL – THEY SEEM TO HELP BYPASS COMPLICATED APPLICATION DISCOVERY
Due to the complicated nature of real-world enterprise applications and their deployments on existing IT environments, it is often considered difficult to discover such an application environment in its entirety for the purposes of cloud migration. While Image-based tools try to make this easier, they take an overly simple approach of “discovering” such existing IT environments. This is especially true for use cases that run legacy workloads, those that may have gone through a series of changes, upgrades and maintenance over their lifetime and, even those that have evolved through a series of changes of IT personnel. It is because of these real-world complexities that discovering such environments along with their custom settings such as dependencies on networking and storage infrastructure and operating environments can be an extremely tedious exercise to “get it right”. It is in fact this challenge that has created the allure of many image-based solutions as a part, or in some cases a replacement for, discovery
The sad truth however, is that even though these solutions have a place, IMAGES ARE NOT SUFFICIENT as, or as a replacement for, discovery. True discovery is needed in order to adequately orchestrate the provisioning, operations and management of applications on clouds and required for enterprise-class cloud computing.
DEPLOYMENT ORCHESTRATION NEEDS DISCOVERY
While creating application or VM images may be a simple task, if the goal is to enable such applications to be deployable, manageable, and scalable on a target cloud, creating images alone is simply insufficient. Despite a push for standards such as OpenStack, the reality is that target private and public target cloud environments have very different underlying compute, storage, and networking infrastructure and very different methods to provision and configure these environments. This invariably requires discovering the application footprint within the images and then reconfiguring the application with custom environment settings, networking interdependencies, etc. in order to provision the application appropriately on the target cloud infrastructure, – an exercise that is cloud specific and most often cannot be leveraged on more than the one unique target environment.
RUNTIME ORCHESTRATION NEEDS DISCOVERY
If one-time provisioning of created images followed by scripted orchestration is not difficult enough, what about auto-scaling, VM tear-down, sprawl control, management, governance policies, policy automation for processes such as disaster recovery (DR) and making changes to the virtual machines based on price/performance, etc. All this requires, not only cloud know-how, but deep down application semantics in order to implement and take full benefit of cloud computing for the given application.
ORCHESTRATION IS APPLICATION DEPENDENT
And, to make things more complicated, these categorical application requirements can vary greatly by various application types. For example, take a complex N-tier application that may require the discovery of all of its tiers, its interdependencies, and where such configuration data may be kept (such as the database IP address in an application configuration file). To provision this application on the cloud, not only would a script need to be created to provision the entire stack in the correct sequence (the database tier configured with the appropriate persistent storage followed by the application server, followed by the load balancer, etc.), the script would also need to configure the application tier with the right database IP address. For a different application such as an MPI based cluster-computing application, or a batch processing cluster, yet again, a very different script-based orchestration will be required for the application to be launched on a target cloud.
HENCE APPLICATION DISCOVERY IS NEEDED FOR ORCHESTRATION
Therefore, an important step in orchestrating the provisioning of an application on a target cloud environment is to be able to perform some type of application level discovery. Discovery is needed to understand the required and optimal infrastructure needed by the application to be provisioned, coordinate with infrastructure, application, data source and service interdependencies and custom settings that are dependent on environment, and application semantics for scaling, DR and general runtime management.
SOME DETAILS ABOUT ORCHESTRATION
Looking at orchestration a bit deeper, it’s not limited to laying and configuring an application on cloud resources, but it’s also provisioning and configuring both the required and the optimal underlying infrastructure as needed by the application to function and perform at its best.
Examples of what such a complete orchestration should do includes:
- Infrastructure Orchestration
- Configuring the right storage (examples: provisioning a shared storage similar to an NFS mounted shared storage, configuring the right drive letters on windows VMs, etc.)
- Configuring the cluster (examples: working with the cloud APIs to launch the right cluster with the minimum required CPU and memory resources, scaling the cluster as needed)
- Configuring the network (examples: vLAN settings, firewall settings, communication protocols, etc.)
- Injecting VMs with the right initialization/configuration data
- Application Orchestration
- Provisioning the application with the underlying infrastructure in the correct sequence
- Configuring the application along the way (such as IP addresses, relative paths)
- Customizing settings and environment
- Configuring security settings
- Runtime Orchestration
- Policy driven tear-down of resources
- Disaster recovery
- Governance controls
No wonder cloud migration has been hard—it’s not just about seamlessly dragging and dropping virtual machines from one environment to another. And since every cloud is different, creating hard-wired orchestration creates lock-in to a particular cloud, eliminating portability that was provided by the images and eliminating the flexibility sought after with the cloud.
The question really is not whether image-based migration can help – IT CAN. It’s just not sufficient. The perceived value it provides can quickly get muted by the required orchestration really needed to get applications to perform optimally on new environments, such as clouds. And, since these new environments vary greatly, having to hardwire images and orchestration to each environment eliminates most of its promise
Being able to create additional layers of virtualization, networking overlays, etc. may be able to potentially avoid some of these mentioned challenges, but often come with significant performance overhead in return. After all, if the whole point of virtualization is to abstract away infrastructure, why would you want to virtualize on top of existing virtualization?
What’s needed is a migration and management platform that provides true cloud-agnostic orchestration on one or more private, public or hybrid cloud environments along with complete visibility and control for fine-grain management and scaling that is not lost when moving between environments.