Minimum Viable Cloud

After a decade of building service-oriented architectures and cloud products for AWS and others, I've had time to reflect on how to distinguish the real from the marketed. Others have taken a crack at this, but explanations that begin with the developer's perspective - the developer who builds and uses new systems on cloud infrastructure - are not especially well represented.

Consider the idea of Minimum Viable Cloud (MVC).

To create an MVC, certain technical requirements must be met. Business benefits are derivative of the implementation, so they follow technical considerations. An MVC is the baseline that a service provider must offer in order to fully deliver on the promise of the cloud. MVC allows developers and users to leverage intrinsic cloud patterns that are emerging and will continue to emerge for years. As this evolution of computing gathers steam and we move from traditional applications to cloud-native applications, MVC characteristics will become more apparent and necessary. They include the following:

Clouds are APIs

All major functions of an MVC are accessible via API. This means very few special features are behind request forms or support requests. If it doesn't have a full coverage API, it's not cloud. We are still in the invention phase of cloud technology, so don't expect API standardization to happen too soon.

Clouds are SOAs

Clouds are service-oriented. I'm not talking about the SOAP-based, monolithic SOA that got popular (and then unpopular due to the predictable scaling and complexity failures of its monoliths), but, instead, the architecture based on REST patterns and asynchronous interfaces. MVCs are made of discrete services that can be composed and orchestrated into higher order business functions.

Clouds Hide Implementation

As any good SOA does, clouds must abstract away implementation so that the cloud provider can improve without too many effects for users. If you have to choose too many details of implementation, you aren't buying cloud resources - you're buying colocated hosting. It's fine to offer some "in the weeds" options, but they shouldn't be required and should always be accessible via API.

Clouds are Fully Automated

If there is a human in the delivery chain from API call to resource allocation, it isn't a cloud. Across the stack, all services in a cloud are accessible via API and return resources without human intervention at the service provider layers. This applies particularly to the unobvious parts of the infrastructure such as firewall rules, software-defined networking (SDN), load balancers, and DNS. All APIs need to have reasonable response time, which varies based on the service. This doesn't preclude customer service functions such as extension of service limits, but all the normal service operations must be fully automated in an MVC.

Clouds are Utilities

If your only option is to buy dedicated or provisioned resources, it's not cloud. Many of the intrinsic benefits of cloud come with shared pools of resources that are sold as utilities on an ad hoc basis. There are exceptions to this, and having additional, non-exclusive options for particular resources doesn't preclude being a cloud, but only having dedicated or provisioned resources does, especially if you have to pay in advance. Being a utility includes having vast scale and elasticity. Electric utilities that have to brown out customers are seen as failing. Compute utilities should be held to the same standard when it comes to predicting and being able to immediately meet customer scaling demands.

Clouds have Global Fault Tolerance

Fault tolerance means the capacity to keep running in anything short of a global catastrophe. This necessitates geographically dispersed resources and integration across those locations. You can't put a cloud in a data center. Clouds are made of many data centers, preferably on multiple continents.

Clouds are Opex

If you have to engage in Capex (capital expenditure), it's not cloud. This would seem to preclude any private cloud, but it doesn't because the engagement is at the business unit or application owner level. If you work for MegaGagillionCorp, and they build an internal cloud and bill you for usage, it's Opex (operational expenditure) to you. Is there any company not dedicated to utility computing that is pulling off a legitimate cloud? Many are giving the windmill a tilt, so it might be best to reserve judgement on whether it's possible. Given that most utility compute providers are themselves struggling to meet MVC requirements as set forth here, it may not be reasonable to think non-dedicated companies will do better.

That's it, but this collectively is a lot to accomplish. Only three public MVCs appear to be out there: AWS, Google, and Azure.

Various OpenStack implementations could get there, but they have a distance to go at present. They can't really be counted for the time being. In particular, SDN is an infrastructure feature of MVC, and Neutron isn't fully baked into a pure API and Opex model available in a full stack service offering.

Private MVC?

It's theoretically possible to have a private MVC, but I've yet to see one outside of the really large and advanced tech companies such as Facebook and Google. There are many efforts at bringing cloudy features to in-house "clouds," but most efforts labeled private cloud are really enterprise virtualization with partial APIs. Perhaps someday this will change, but the organizations that truly have the scale and diversity of load to get ROI on the required Capex are likely few and far between. This doesn't mean that adding some cloudy features to traditional data centers is without merit. Often cloudy features such as APIs for compute, SDN, and object storage have legitimate non-cloud business functions. Having the ability to span a distributed system across cloud and private infrastructure is compelling if there are legal or regulatory reasons to keep data in-house.

The takeaway is that MVC is defined by a practical set of requirements. They allow builders to transition from moving existing workloads onto the cloud to crafting cloud-native applications and, ultimately, to developing future cloud architecture with minimum pain and cost. As an ex-Amazonian, I'd note that this customer path is the road less traveled, but it will make all the difference. Netflix is ahead of the curve, but many talented developers are still hashing out exactly how to build on the cloud. Use a service provider that is at least MVC. There are three of them out there now.

The next post in this series will be More than the Minimum (C>M)", a look at what mature cloud implementation really means.