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)