PaaS (platform-as-a-service), once dead, is resurrected. You can blame Kubernetes. Or maybe just fear of the freedom the public cloud can offer developers.
Enterprises, eager to give their developers a certain level of autonomy, have turned to Kubernetes-based platform services that help separate development and operation, allowing developers to be the “kingmakers”. without cleaning up the mess† What remains unclear is whether such attempts to limit developer choices can succeed in a world where developers are already just an AWS, Google, or Azure console, far from unlimited freedom.
We’ve seen this movie before
But first, it’s worth pointing out that for most developers, as much as they dream of “unlimited freedom”, they’re not quite the Redmonkian kingmakers they might want to be. As big as public cloud computing has become, it remains a rounding error compared to total IT spend. For most developers, the CIO is usually the ‘last to know’, but they retain quite a bit of control/influence over developer decisions.
SEE: Hiring Kit: Cloud Engineer (Tech Republic Premium)
No wonder, then, that Gartner analyst Lydia Leong can invest quite a bit of time advising customers about enabling developer self-service, which is a lot like PaaS and, really, is PaaS, despite our weird resistance to call it that† Perhaps one of the reasons we resisted the “PaaS” label is that PaaS didn’t catch on, as David Linthicum explained. Or perhaps, as he suggested, a separate PaaS no longer makes sense, given the ambitions of the cloud providers: “[T]The lines between IaaS and PaaS have blurred to almost invisible as AWS, Microsoft and Google continue to add features and functionality that fill the gaps between the two cloud computing models, especially around app development.”
Whatever we call it, why are we talking about it again? Why didn’t we put Heroku and Google App Engine and the like to rest? Why do we persist? in the hope that the public cloud will disappearthat “private cloud” can and should be a thing?
Because if Google’s Kelsey Hightower noticed in 2017, “[T]The majority of people who manage infrastructure just want a PaaS. The only requirement: it must be built by them.” In other words, they want cloud, but they also want to control that cloud. It is this desire for control that keeps the PaaS dream alive. It’s what continues to drive even growth startups to keep rebuild the cloudtime and time again to their image in hopes that somehow they come up with a better AWS than AWS.
In the process, VMware’s Michael Cote argued:, we continue to create our own custom clouds and accompanying big price tags: “If you want to migrate to a new platform (on-prem helpdesk/ITSM to NOW SaaS), you also charge (often shocking) costs a lot of customization.” Which begs the question, why are we all building our own little snowflake “developer self-service platforms” (aka PaaS) when there are more vanilla solutions, otherwise known as the public clouds?
Some guardrail mounting required
As always in enterprise IT, it’s a matter of control. In fact, it is an attempt by organizations to find the right balance between development and business operations, between autonomy and management. No two enterprises will land exactly alike on this freedom continuum, arguably why we see every enterprise committed to building its own PaaS/cloud. Going back to Coté’s comment, the costs associated with being a snowflake can be high.
SEE: The Best Serverless Computing Solutions (TechRepublic)
One solution is simply to give developers freedom… up to a point. As Leong emphasized, “I talk to far too many IT leaders who say, ‘We can’t give developers cloud self-service because we’re not ready yet. You build it, you run it!’ after which I must gently but firmly remind them that it is fine to give your developers full self-service access to development and test environments, and the ability to build infrastructure as code (IaC) templates for production, without having to completely responsible for production.” In other words, companies may not need to hand over the keys to the kingdom to their developers; the garage will do.
Timothy Loy Sutherland, Senior Director Cloud Enablement and Architecture at financial services software company Finastra, provided a thoughtful approach to designing crash barriers around a self-service developer platform. In Sutherland’s world, the key to success seems to be building with standard tooling, rather than going overly customized: “Standard infrastructure patterns, provided by Azure Kubernetes Service (AKS, for example), enable developers to build their services regardless of the infrastructure or code language requirement, without requiring infrastructure knowledge and operational expertise.”
This is the golden mean that Redmonk analyst Steve O’Grady stated: in a series of tweets. For O’Grady, crowning developers as “kingmakers” doesn’t mean giving them absolute control to do what they want. But it is also a counterbalance to absolute IT policy that do not allow developers to use preferred cloud tools. Citing the example of Netflix’s “paved roads”, O’Grady called for “an IT-tested and supported core platform” which is recommended.” Dan, “if unique requirements force a team down that road, so be it, but then they’re on their own for literally everything.” Developers will presumably prefer the “paved road” over their own pavement. Everyone wins.
This is exactly what companies like Weaveworks are trying to do, as Alexis Richardson, Weaveworks CEO, explained to me in an interview. Weaveworks is intentionally multicloud (or, perhaps more accurately, runs wherever Kubernetes runs), so that the platform developers can choose that transcend any specific cloud/OS environment, giving them even more freedom. Kubernetes can be notoriously difficult for developers because it lacks features like continuous delivery or observability that we’ve come to expect from a platform. Weaveworks solves this problem by adding these developer-friendly features and making the platform open source so that it can be run anywhere. Companies get a standard platform, but also a platform that they can tailor to their needs. Tearless adaptability, if you will.
Yet we still don’t quite answer the essential question. As Coté put it“’PaaS’ as its own category makes sense if you’re using FUD (real or just perception) on the public cloud and need to build your own set of cloud-like services. What we should really be talking about is… using the AWS, Azure, or Google Cloud stack.” Or, slightly less dramatically, he explainedrather than FUD (fear, uncertainty, doubt), it might be better expressed as “reasons, factual or imagined, for not just using the public cloud.”
Are self-service developer platforms, or the latest incarnation of PaaS, just a way to fend off the inevitable future of the public cloud? Could be. But whether it’s good or not, many enterprises aren’t ready to go fully cloud-native and want to keep trying to balance public cloud autonomy with a bit of old-fashioned security and control. or if AWS impresario Massimo Re Ferrè said:† “Finding the right balance between ‘doing the right thing’ and ‘being innovative’ is incredibly difficult.” Same as it once was.
Disclosure: I work for MongoDB, but the views expressed herein are mine†