From Cloud-ready Apps to App-ready Clouds

An old King does not like to change his ways. He wants his court to always look the same. Wherever he travels, he brings his entourage with him, and they set up the same scene and the same amenities. Since nothing should make the King uncomfortable the courtroom translates the new ways of the world for him in a vocabulary that he understands.

An old King's courtroom is full of lies and so is Computer Science.

Programmers are not liars, but infrastructure is. The age-old art of lying is what we euphemistically call virtualization.

Lies upon Lies

Back in 1964, IBM’s System/360 was the first line of processors allowing applications to run without any change on a range of different hardwares. This was an acknowledgement of the fact that changing applications in response to infrastructure change was hard. Even after half a century, many of those applications that were written in the '70s still run unmodified on today's IBM Z series systems!

Around the same time, to fool Apps to believe they had all the memory in the computer for themselves, we started lying about Memory, calling it virtual. In 1987 we started lying about disks, calling it RAID, and eventually leading to NAS and SAN technologies. In 2003, we started lying about networking, calling it VLANs.

Now, isn’t that when hypervisors were also introduced? Not really. In fact, the notion of hypervisors dates back to 1967 when in a beautiful paper, Popek and Goldberg described not only Type 1 and Type 2 hypervisors, but also the notion of recursive/nested hypervisors. What IBM introduced in the 1960s, VMware made mainstream in the 2000s.

While on the surface, computer science seems to evolve rapidly, most innovations in computer architecture have been focused on making the App believe that nothing has changed around it.

The App is the King of the data center. So, isn’t it blasphemous in the King’s court to ask for him to become Cloud-ready ?

Is the ‘Cloud’ so powerful? Is the ‘Cloud’ God in the eyes of the App?!

No!

And this is where, as an industry, we are getting things confused. The reality is that the Business is God; and Cloud is just a servant. The Business funds the App, and only the Business can force the App to change.

App Mimics the Business.

In more than half of century of datacenter innovation, for the first time the App is changing -- forced by the business that created the App in the first place.

Apps do not merely support the business; today Apps are the Business.

Apps now have to mimic how the business works. They are designed with Microservices (like business units) that self-manage, scale independently and respond quickly to customer demand; each microservice having a clean API and ownership for what it delivers (like departmental contracts and responsibilities). Much like the business, the App is expected to be global, always on (24/7/365), and resilient to failures (analogous to succession plans for individuals, dual parts suppliers, etc.).

This new type of App that mimics the business is what we have started to call native cloud apps or Mode 2 apps. These new Apps have very different needs, and they are essentially being rewritten using cloud-native services.

While the transition happens, and business are becoming bimodal with two goals:

1. Rewrite apps that are critical to business agility to become cloud-native (Mode 2).
2. Improve the agility of running the existing (Mode 1) apps so that they do not become a deterrent for the business.

If all you have is a hammer ...

Encouraged from some of the early success of building native cloud apps in the public cloud, the recent excitement has been around migrating legacy apps to the public cloud for agility. While on the surface it seems that a lift-and-shift of legacy apps should work (even though it has been observed to be very expensive), in reality it requires painful changes in the environment of the App, and half a century has taught us that this old King liketh it not.

The talk about Cloud-ready apps, is nothing but a euphemistic way for mandating a series of changes to legacy (mode 1) apps to make them run in the cloud. Let's list a few of the changes required:

1. Retooling of how the Apps are provisioned (APIs and SDKs are different in the cloud)
2. Changing processes for troubleshooting Apps. The cloud commonly does not give visual console access, and does not expose infrastructure problems. Troubleshooting apps in the cloud is a different skill to acquire.
3. Changing management of Apps. Basic things like renaming of a VM that is taken for granted on-premises, is not available in the some public-clouds like Azure and GCP!
4. Retesting Apps because Instance Types do not always match with on-premises resource ratios, inevitably changing the App behavior.
5. Changing the design of the App since the cost-structure is different in the cloud forcing the App instance type decisions to be different -- leading to more unknowns.
6. Changing the way VMs are prepared via sysprep or cloudinit.
7. Changing the way how commands are executed in the VMs (ESXi vs. AWS).
8. Changing the way RBAC is done -- Cloud IAM vs. on-premises hypervisor-based RBAC.
9. Changing the way the in-cloud apps integrate with the systems of record.
10. Changing the way alerts are integrated with the ticketing systems.
11. (.. the King's face turned red with fury as he threw this list into the fire.. )

Why should the legacy App, that has refused to any change in the last 50 years, agree to such widespread changes? It is a fallacy to believe that these apps will find themselves 'at home' in clouds that were primarily built for native cloud apps.

It is time to build App-ready Clouds.

An App-ready Cloud is a cloud that does not require legacy apps to change, while providing cloud-native services for next-gen apps -- for both on-premises and off-premises deployments.

An app-ready cloud can cater to the rising bimodal demand in enterprise IT today to seamlessly bridge the gap between the public and the private, for both the legacy and the modern apps.

Let us define the key characteristics for App-ready Clouds (whether private or public or hybrid):

1. Always-on, everything scale out. (Clouds don't sleep)
2. One-click operations from bare-metal to App. Infrastructure should be invisible.
3. Powerful, simple management at scale (farming mentality).
4. Elimination of human-error via automation and fail-in-place design.
5. Reduction of mandated human-expertise via machine-learning. (No need to hire expensive experts)
6. Portability of tooling across public and private clouds. (Cloud is just a servant -- make it work harder for you)
7. Portability of troubleshooting and initial provisioning (console access, sysprep, etc.) across public and private clouds. (Ask for more transparency in public clouds)
8. Ability to manage both ‘pet’ apps (require renaming, resizing, etc.) and ‘cattle’ apps.
9. Portability of resource ratios across clouds. (Instance types should be flexible)
10. Portability of currency across private and public clouds. (Move investments between public and private clouds)
11. Common Authentication and RBAC mechanisms across clouds.
12. Custom performance specification (Control) and QoS guarantees.
13. BYOL across private and public.

Nutanix has announced the plans for such an App-Ready cloud, built atop years of scale out, always-on, distributed-systems engineering, with a delightfully simple management experience for both public and private data centers.

It’s not about Cloud-Ready Apps, it is about App-Ready Clouds.