Skip to content
The M in MVC (Minimum Viable Cloud) implies that there are additional capabilities in a mature cloud implementation beyond those outlined in our previous post, which introduced MVC. Recall those sine qua non MVC requirements:
  • Clouds are APIs
  • Clouds are SOAs
  • Clouds Hide Implementation
  • Clouds are Fully Automated
  • Clouds are Utilities
  • Clouds have Global Fault Tolerance
  • Clouds are Opex


Additional capabilities that constitute fully developed cloud ("C") exist in areas like service offerings - having more of them, such as object storage or noSQL databases. But, metaprogramming capabilities that allow you to compose and orchestrate systems across resources are the centerpiece of C.


Let's get specific.


C>M Clouds promote stateless, distributed compute


Cloud-native applications treat compute instances like processes: you run them and put them away when done. Doing this requires that your compute is largely stateless. This means you need a good place to put all your persistent state outside of where you compute. For the compute services, this means you need to be able to buy in small time increments, have full control via API, and have an orchestration capability for running your system. For now (but not for much longer!), you'll have to roll your own orchestration, but you can buy this kind of compute from several providers.


C>M Clouds have asynchronous messaging


You can't easily get to statelessness and distribution without assured delivery asynchronous messaging. It should be the first choice in tying together your services, as it doesn't require known end points that you want to make ephemeral and disposable. You need asynchronous messaging to compose a cloud-native application.


C>M Clouds have data persistence as a service


You can't easily build a cloud-native application without storage utilities. Making most of your application stateless means you need a robust, highly available, and highly scalable place or places to persist data. This should minimally include an object storage system and a noSQL database.


This collection of C>M features allows the construction of n-scale applications (n being dependent on the service provider's overall scale and innovation to allow scaling), without you doing the heavy lifting to create the infrastructure. It also allows you tremendous business agility since you aren't tying your business decisions to infrastructure provisioning. To fully leverage these features, you need a powerful control and orchestration solution that you either make yourself or buy. That solution will be available soon for AWS from Luminal.


The future of computing lies in the ephemeral use of on-demand resources based on business need. To get there, we must have support for patterns such as immutable infrastructure, disposable compute, automatic scaling, asynchronous communications, and distribution of stateless components. Assuming genuine cloud compute is available, the observant reader will say that all these features can be built out of compute nodes. While true, this isn't a great model in most cases because users end up paying for a package of provisioned, dedicated compute as opposed to an on-demand, pay-as-you-use stream of compute. The kinds of applications that fully leverage the patterns noted here and the M + C capabilities of cloud are indeed what we mean by cloud-native applications.


The next post in this series is on Future Clouds and explains a little more about what we're working on at Luminal... stay tuned.


Categorized Under