In part two, we will talk about how appropriate architectures for cloud applications and open standards can reduce the difficulty in migrating applications across cloud environments.
A good deal of time and money in the IT industry has been spent on trying to make applications portable. Not surprising, the goal around migrating applications among clouds is to somehow make applications more cloud-portable. This can be done in at least three ways:
Architect applications to increase cloud portability.
Develop open standards for clouds.
Find tools that move applications around clouds without requiring changes.
Most of today's large, old monolithic applications are not portable and must be rebuilt in order to fit the target environment. There are other applications that require special hardware, reducing their portability, and even many of the newer applications being built today are not very portable, certainly not cloud portable.
Application architectures and the cloud
Numerous cloud experts have indicated how important an application’s architecture reflects on the ability to move it from one cloud to another. Appropriate cloud application architectures are part of the solution to cloud interoperability, and existing applications may need to be re-architected to facilitate migration. The key is trying to architect applications that reduce or eliminate the number of difficult-to-resolve dependencies between the application stack and the capabilities provided by the cloud service provider.
Bernard Golden, CEO of HyperStratus, has noted that, to exploit the flexibility of a cloud environment, you need to understand which application architectures are properly structured to operate in a cloud, the kinds of applications and data that run well in cloud environments, data backup needs and system workloads.
There are at least three cloud application architectures in play today:
Traditional application architectures (such as three-tier architectures) that are designed for stable demand rather than large variations in load. They do not require an architecture that can scale up or down.
Synchronous application architectures, where end-user interaction is the primary focus. Typically, large numbers of users may be pounding on a Web application in a short time period and could overwhelm the application and system.
Asynchronous application architectures, which are essentially all batch applications that do not support end-user interaction. They work on sets of data, extracting and inserting data into databases. Cloud computing offers scalability of server resources, allowing an otherwise long running asynchronous job to be dispersed over several servers to share the processing load.
Platform as a Service (PaaS) providers provide tools for developing applications and an environment for running these applications. To deliver an application with a PaaS platform, you develop and deploy it on the platform; this is the way Google App Engine works. You can only deploy App Engine applications on Google services, but cloud application platforms such as the Appistry CloudIO Platform allow for in-house private cloud deployment as well as deployment on public cloud infrastructures such as Amazon EC2.
Where the application is developed and where it is to be run are factors that feed into the application architecture. For example, if you develop in a private cloud with no multi-tenancy, will this application run in target clouds where multi-tenancy is prevalent? Integrating new applications with existing ones can be a key part of application development. If integration involves working with cloud providers, it is difficult because cloud providers do not typically have open access into their infrastructures, applications and integration platforms.
Older applications that depend on specific pieces of hardware -- meaning they'll want to see a certain type of network controller or disk -- are trouble as well. The cloud provider is not likely to have picked these older pieces of hardware for inclusion in its infrastructure.
In your efforts to migrate applications, you may decide to start working with a cloud provider template where the provider gives you an operating system, such as CentOS or a Red Hat Enterprise Linux template. You'll then try to put your applications on it, fixing up the things that are mismatched between the source application environment and the target environment. The real challenge is that this approach becomes an unknown process, complete with a lot of workarounds and changes.
As you move through a chain of events, fixing problems as you go, you are really rewriting your application. Hopefully you won't have to rewrite it all, but you will surely change configurations and other things. You are then left with a fundamentally different application. This could be good or bad, but either way you'll have at least two versions of your application -- the data center version and the cloud version.
If moving an application back and forth between your data center and a cloud (or from one cloud to another cloud) results in two different versions of the application, you are now managing a collection of apps. As you fix and encounter problems, you'll have to work across however many versions of the application that you have created.
Cloud standards and application migration
Open cloud standards are considered the eventual solution to issues around application migration and cloud interoperability. We view cloud standards as a collection; this one starts at the low level with something like OVF (Open Virtualization Format) that gives you a universal language for describing the metadata and configuration parameters of virtual machines. At the next level, something that would describe the environment -- the connectivity between virtual machines -- would be useful. This would give you the networking between the virtual machines and the functions and scale of the environment in which the virtual machines operate.
MORE ON CLOUD APPLICATIONS:
How to build an application for the cloud
Applications interfere with cloud computing adoption
It is unlikely that we will see cloud standards being adopted this year or next year, for reasons that include ongoing innovation. Vendors such as VMware would love to just say, "We will do the whole black box thing for you: buy our stuff and you can put up a cloud and offer it to your customers." The cloud providers are not thrilled with this idea because they want to differentiate their services. They don’t want to go the route of standards if clouds are then driven to commodities. If and when we have standards, there will almost certainly be a problem with how cloud providers do or offer unique things on top of standards.
John Considine, the CTO of CloudSwitch, notes that for a cloud provider, a standard provides customers with what they want and provides a guideline for how cloud is implemented. In the case of the VMware vCloud API -- which has been submitted to the DMTF for ratification as an open standard for cloud APIs -- VMware dictates how cloud environments are configured and accessed with respect to things like definition of resources and catalogs of virtual machines. These "mandates" have a direct impact on how a provider implements its cloud.
What are some hints for architecting cloud applications? One suggestion is to design the application and its supporting stack components not to rely on the operating system and the infrastructure. The more you do this, the better off you will be with respect to interoperability and application migration. If you can use mature fourth-generation languages or interpretive systems to build applications, then you will also have a better chance for interoperability.
The problem you might run into is not getting the performance and/or the functionality you need. In addition, you may have to avoid certain performance and capability benefits that could be available with hypervisor tools or from the specifics of an operating system. You also might have to go for a generic operation of your application with min-set functionality to make it portable from cloud to cloud.
What kind of existing applications are good candidates for running in the cloud? The more generic and higher level the application is, the greater your chances of moving it from cloud to cloud. One of the cloud's weakest areas is in needing total control over the operating system. If you are running an old version of Linux or Windows, then you are probably in trouble; most public clouds do not support older versions of operating systems. This is a dating problem, as applications written before a certain date are not easily movable.
Migrating applications among clouds is not easy. But open standards for cloud computing, when they appear, and the advent of tools such as CloudSwitch and Racemi will ease the difficulty and make hybrid clouds more of a reality.
