With the success of VMC on AWS, it’s time for us to admit that the Cloud Native programming model as the dominant and only programming model for the cloud is dead.
The Cloud Native programming model was a godsend for IT and software engineers. The move from CAPEX to OPEX forced all of the pre-existing software that ran on premises to be completely re-written for the cloud.
Jobs, careers, and consulting firms exploded as everybody tried to go on this cloud journey.
It was like the great y2k rewrite, which was followed by the C++ rewrite, which was in turn followed by the great Java rewrite …
This rewrite was forced because On-Prem software assumed infrastructure that did not exist in the cloud and could not work.
On-premises, you have very reliable and robust networks, storage that offers 5 9’s reliability, and a virtualization infrastructure that provides automatic restart-ability of virtual machines.
Furthermore, on-prem you had the opportunity to right-size your VM to your workload instead of playing whack-a-mole with the bin-packing strategy known as “which cloud instance do I buy today?”
The problem with on-prem was that you had to buy the hardware, and worse you had to learn how to operate the hardware.
The operating environment for the cloud where networks are unreliable, storage is unreliable, and applications must be HA aware and integrate with HA aware systems required a full-rewrite of perfectly fine working software.
What motivated this mass migration and mass rewrite?
The motivation was that new software could legitimately be written faster on the EC2 PaaS. Furthermore, companies didn’t want to own the hardware and wanted to rent their infrastructure.
The two factors pushed companies to look at Cloud Native not as a way to augment their existing software assets, but a once-in-the-lifetime opportunity to rewrite their software assets.
But it turns out that is hard. And it also turns that the pre-existing operating model on premises is kind-of-valuable. Instead of every application having to figure out how to deal with infrastructure that’s flaky, it’s just simpler to have a more robust infrastructure.
And now that the cost and agility advantage of the cloud has been in-part neutralized, what I hope we might see is a collective pause in the software industry as we ask ourselves – not whether it’s on-prem or cloud-native, but what is the appropriate programming model for the task at hand.
This article skips a few too many steps in its arguments … “And now that the cost and agility advantage of the cloud has been in-part neutralized” (?why? by what?) and “The motivation was that new software could legitimately be written faster on the EC2 PaaS” (why? Did you mean new extensions to existing software with the word ‘new’? Or is there something more productive in the cloud environment? Certainly its even cheaper not to migrate all and to simply keep your existing software platforms in-house …)
In our experience at Lyft, cloud is a great place to germinate, but a bad place to terminate your company’s growth strategy. cloud is only cheap if you are starting out ~ as you get bigger and bigger the pricing models keep the profits from the economies of scale inside the pockets of the cloud provider, refusing to share them with customers.
Don, thanks for the excellent points. I am going to do a follow up expansive post to make my arguments differently
Good points.
My point was that companies with software written for on-prem infrastructure to go to cloud had to rewrite it to get cloud properties like OPEX.