What Is Meant by a "Cloud-Ready" Application?

Is calling an app "cloud-ready" just a form of cloud-washing?  C'mon - aren't all apps "ready for the cloud" (and for that matter, ANY cloud)? Doesn't IaaS and its elastic capacity + automation solve for all app scaling and configuration issues?

You'd think so if you listened to all of the accolades paid to the public cloud these days. But as I dug into the complexities of maintaining sophisticated app landscapes, just dropping them onto a public IaaS cloud only helps to a point.

Why? Because a complex landscape will include many servers (often virtual machines) linked by unique network topology (including load balancing, firewalls, etc.) connected to differing forms of storage (not to mention storage tiering, backup etc.) and all choreographed to work together in a specific manner with unique rules.

Only your ISV and app architect know for sure...

It turns out that IaaS (and/or PaaS) infrastructure foundations are necessary, but not sufficient solutions to allow app admins to fully maintain complex app landscapes in the cloud.

Why? It's because these landscapes don't fully self-manage the app environment. They don't interact with the applications' unique configuration rules and procedures. They don't have knowledge that only the ISV can have regarding optimal capacity and topology. And they can't predict what changes to make until told to do so.  Thus, most cloud hosting scripting - while convenient - is still a but of a kludgey solution if you really understand the specific application.

And the system gets another layer of complexity when you consider that different (public/private) clouds may embed differing properties. So if/when an admin wants to redeploy the app on a different cloud, he faces another headache.

Enter: ISV App Orchestration
Admittedly, I believe "orchestration" is another nebulous concept next to "automation" and other over-used terms.  But in the context above, let's consider "App Orchestration" and where it can help.  Later on, I'll give a few examples of providers who are currently solving the problem.

As I mentioned, the best forms of App Orchestration ought come directly from the ISVs themselves. Presumably they know the the ideal configuration dynamics, SLA controls and more. Specifically, app orchestration (AO) ought to provide the following:

• Blueprints for landscapes - The AO engine/layer must necessarily start with knowledge about the required app landscape and topology - and be capable of initiating it. Somewhat akin to AWS CloudFormations, the AO layer must be able to invoke a partial or entire instance of the app - for a specific scale or a given infrastructure. Such blueprints or templates then serve as starting points for other topologies and/or governing rules.
• Operating (or dynamic) orchestration - At the core of the AO layer is logic around optimal adjustments to compute (number and location of app images and VMs), network (including load balancing and QoS), and storage (connectivity, tiering, caching). Balancing these resources is not necessarily linear, and differing use cases for the app may impact how these resources are combined. In general, only the ISV architect may have knowledge about such workflows and optimizations.
• Goal-based automation - Even if you set up an app landscape on top of IaaS, it doesn't guarantee administrators won't have to adjust it in the future. Say you want to re-optimize around a specific SLA (or combination of SLAs). Or that you want to scale the system in advance of new users. This feature helps set (and sequence) future-state goals for the system to attain and maintain.
• Multi-cloud deployment - There are many pure-play vendors currently on the market that facilitate deployment onto differing public clouds (e.g. Rightscale, Scalr, enStratus) but none operate from within the app administration console. This allows the app admin to determine as part of the apps own policies, where and when to place workloads on differing private and/or public clouds.
• Multi-version management - Any vendor should recognize that larger customers with multiple locations will likely be running more than one version of their software. AO needs to recognize this reality, and orchestrate landscape instances (or even parts of landscape instances) that may have various versions.
• Multi-tenant management - Again, any vendor should recognize that larger customers (and especially service providers, SIs, etc.) are likely to need to manage separate/isolated tenants on the infrastructure. AO needs to recognize this not so much from a role-based admin perspective (a prerequisite) but from the perspective of maintaining isolation of one landscape while being capable of manipulating another.

Next: Suite Orchestration?

I also wanted to share a brief thought here: What would a "cloud-ready" software suite look like?

We all know that large software and platform vendors (think: Oracle, SAP, Microsoft, Symantec, Citrix, CA, IBM, HP etc.) offer tons of what they call end-to-end software. They all say that their SW is integrated.  But can they all claim that those suites are cloud-ready? Can they all be orchestrated as an integrated system together?  Probably not. Not yet anyway. Which leads me to the next section...

App Orchestration: A new (required) layer for ISVs?

Traditionally, ISVs (and their customers) have had focus on code, on APIs, on performance tools, and on management/monitoring software.

However, during the recent virtualization era, the push has been for ISVs to go further and ensure that their apps can be virtualized and supported in an entirely virtualized data center.

As we now enter the Cloud Era, I believe ISVs delivering complex apps and/or app suites will be required to provide intelligent orchestration when those app portfolios are run in a cloud environment. That means "north-south" orchestration, i.e. how the software interacts with the IaaS/PaaS layers, and "east-west" orchestration, i.e. how the software interacts with other components/products from the vendor.

The "east-west" coordination is what I find most intriguing. That might mean continuous orchestration between specific apps and networking, storage, firewalls, IaaS, DBs and more. Across all products from a given ISV's software suite.

This would shift the notion of a vendor's "suite" from being a loose aggregation of apps and tools, to one that was indeed cloud-ready and orchestrated as a system. Even if only for use with an on-premesis cloud.

Will vendors begin to acquiesce the need for true orchestration in a cloud? I hope so. The ISVs are really the only ones with the deep knowledge to do so. And in the Cloud Era, the value to customers would be immeasurable.



Other Resources

• App Orchestration Concepts [Blog] Ashish Gujarathi
• Wikipedia on orchestration
• IBM DeveloperWorks on Cloud Orchestration [Blog]
• ISVs doing this?
• OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA)

A Tale of Two Cloud Strategies

These are the best of times. These are the the worst of times. These are the times of the "cloud era" where two technology leaders are struggling to dominate the IT infrastructure, private cloud, and public cloud markets.

Two recent announcements lead me to making an interesting business strategy observation about two opposing approaches to dominating these markets:

• VMware's recent announcement that it intends to venture into the public cloud (assessment courtesy of James Staten)
• Amazon Web Service's recent (re) announcement of its Virtual Private Cloud (VPC) functionality as it ventures into the enterprise (on AWS Blog) as well as their recent teaming with Equinix and Netapp

As they mature, each company is trying to stake a claim in the others' territory. VMware venturing into Amazon's domain, and Amazon's venturing into customers dominated by VMware. 

AWS: A Strategy Going from Public to Enterprise

Let's first examine Amazon AWS. These guys essentially pioneered the public IaaS cloud. Early users were dev/test engineers, experimenters, and special projects teams to see how far they could push the cloud. Arguably these users remain the mainstay of AWS. But Amazon realized that it needed to grow beyond these early-adopter audiences.

And, AWS has steadily improved on their platform. Not just in raw size, but in services. It seems not a week goes by that AWS doesn't announce another service API for their cloud. One could argue that taken in total, AWS is constructing the de facto public cloud operating system.

But they've also recognized that growth depends upon expanding into and winning-over the enterprise with additional services, security and business-models that CIOs expect. I see VMware pursuing 3 strategies to do so:

1. VPC - Creating an extension of an enterprise's network and data center within a virtual private cloud hosted on Amazon's infrastructure
2. Public API - Tacitly (or explicitly) allowing 3rd parties with an enterprise presence to use the AWS set of APIs. Be it Eucalyptus, OpenStack, ASF CloudStack or others, Amazon knows that when enterprise software and IT skills are designed around their APIs, they ultimately win - since switching costs from deploying in the enterprise to deploying in EC2 become nearly zero.
3. Channel distribution - Amazon also knows that enterprises like to buy through trusted distributors and value-added resellers. AWS has been savvy in allowing the traditional channel distribution mechanisms to have access to AWS (at a reseller discount, of course).  Traditional channel VARs know that they ultimately have to develop business models with AWS, lest they be cut-out of the value-chain by customers going direct.

VMware: A Strategy Expanding from Enterprise to Public

In somewhat contrast, we have VMware. A leader in enterprise virtualization and management, VMware has been pursuing domination in enterprise IT focusing on its own virtualization and infrastructure management technologies - not to mention a cloud framework and sophisticated management tools.

VMware also believes that a strong ecosystem of hosting providers and cloud service providers will help it cement its technology in the market. By encouraging those partners to build their own clouds and services on top of its products, technologies and APIs they hope to expand the prevalence of their platform and use by enterprises - since many of these partners already have relationships with the CIO.

But recently (IMO) VMware has acquiesced that it needs more clout in the public cloud space to maintain growth in a quickly-saturating Enterprise virtualization market (threatened by Microsoft, Citrix, and others). Thus, they recently announced the intent to develop a hosted Hybrid Cloud service.  The intent would be to offer existing VMware customers what would appear to be a seamless extension of their virtual infrastructure into VMware's own hosted virtual infrastructure.

Whether this turns out to be a true public cloud (as in a direct competitor to AWS) remains to be seen. And even though this new service is expected to be sold through VMware's existing channel, there is no doubt that it will cause some channel conflict with their existing hosted service providers.

Nonetheless, this strategy clearly marks VMware's move into the public cloud style of business, perhaps encroaching into Amazon's VPC space.

What's Next: More of the Same

These sorts of growth strategies are not new to business. Companies continually try to go expand into adjacent markets when growth begins to stagnate or when competition gets fierce. No difference here.

These will be extraordinary strategies to observe over time. We all know that even the most dominating companies/technologies eventually meet their match (or their disruption).  Both VMware and AWS have appeared at times to be unstoppable. As they converge, it will surely be a battle of gladiators.  Unless (or until) of course, third, fourth and dark-horse players disrupt the party. As they always do.

Follow-on Blog: A Tale of Three Cloud Strategies (added October 2013)