Cloud differentiators part 1: Private versus Public

When Werner Vogels visited us at Société Générale in 2016, he gave a brilliant speech on microservice architectures. Two particular things he mentioned turned out to be real head-scratchers for me: 

• While containers are billed per VM per hour, functions are billed per memory per second because the former run on top of EC2 instances. This seemed to imply that the latter were not, which at the time of speaking could not be. If it is true that the billing model was different between Lambda and ECS, the underlying compute layer was indeed the same;
• Mr Vogel made copious allusions to the sophistication of the then recent ECS orchestration engine in a context where Docker UCP was getting most attention. Back in 2016, stating that Docker was lacking experience as opposed to a Cloud Provider seemed bold, and, in fact, only AWS and Google could have the pretense to pose themselves as serious challengers to the nascent Docker orchestration platform. We all know how this battle ended for Docker…

The micro-VM revolution

So what message was the AWS CTO trying to convey? In hindsight, it’s clear he gave a hint on the future of microservices. This future was resting on micro-VMs and micro-managers. It now seems obvious that in late 2016, the R&D teams in AWS were already actively busy building this revolutionary pattern. 

Revolutionary? When firecracker was announced at reinvent in 2018, I explained the rationale behind micro-VMs and why they are such groundbreaking inventions. 

But there's more to it now: up until a few days ago we had to contend with the firecracker source code on github to understand the power of AWS micro-VMs. Although an immensely useful source of information, this project was shared out of an operational context. Put it another way, the “dev” end of “devOps” was fully covered, but the “Ops” end wasn’t at all.

With the recent publication of the first research paper on firecracker technology, we now get a complete overview of a micro-VM devOps chain. Without getting wonky, the top merits of the article are:

• firecracker is placed in the operational context of a real service (Lambda);
• acceptance criteria are defined for operating micro-VM environments.

Now, which Cloud strategy? Benchmarking Private versus Public cloud

If we want to articulate an educated comparison between Private and Public Cloud strategies, I believe that some of the firecracker acceptance criteria provide an invaluable baseline.

Micro-VMs lie at the deepest level of infrastructures, so their impact to an IT strategy might seems to be limited to IaaS, however the reality is that

the deepest you optimize your infrastructure, the highest you amplify the gain on your TCO. So the impact of micro-VMs on PaaS an SaaS is huge.

Let’s take a close look at Amazon criteria:

1. Overhead and Density: the more workloads you can pack on a single baremetal server, the better. It’s clear that if Private Clouds keep their current density, their TCO will increase dramatically over the next few years;
2. Performance: micro-VMs perform as good as containers, so Public and Private Clouds are on par on this one I think;
3. Fast switching: same as above: there's no significant difference;
4. Compatibility: AWS micro-VMs only supports Linux-based systems, but Azure micro-VMs based on hyper-V support Windows of course;
5. Soft allocation: Multi-tenancy in the Public Cloud has always brought economies of scale, it even stands at the core of the business model. I believe with the authors of the firecracker article that the low grain provided by micro-VMS amplifies this considerably. I doubt Private Clouds will have the ability to match Public Clouds even if they implement micro-VMs themselves. We should see a big increase in TCO for private Clouds over the next years just because of that;
6. Isolation: today there is no consensus in the community of Cybersecurity experts as to whether the level of isolation of micro-VMs is equivalent or less than VMs. Not that many experts have worked on the subject, many don’t have first hand information, and academic papers are close to non-existent. All I can say is that firecracker has been battle hardened for nearly two years now in AWS Lambda (more recently Fargate as well), and that so far, the people who have audited the code of firecracker (including myself) have not found any caveat worth mentioning. 

It looks like Density and and Soft allocation are 2 key criteria that would need to be measured or revisited by any corporation starting its private Cloud transformation: as of 2020 the public Cloud could be a much wiser choice, TCO-wise.

I hope the instrumental firecracker paper will help raise interest on micro-VMs by the IT security community and that it will help decision makers, software vendors and IT strategists steer the Private Cloud model into a sustainable direction.