PaaS is back: Why enterprises keep trying to resurrect self-service developer platforms

PaaS (platform-as-a-service), once dead, is being resurrected. You can blame Kubernetes. Or maybe just fear of the freedom that public cloud could bring to developers.

Enterprises, eager to give their developers a certain level of autonomy, have turned to Kubernetes-based platform services that help separate development from operations, enabling developers to be the “kingmakers” without having to clean up the mess. What remains unclear is whether such attempts to constrain developer choices can succeed in a world when developers are already just an AWS, Google or Azure console away from unfettered freedom.

We’ve seen this movie before

But first, it’s worth pointing out that for most developers, however much they may dream of “unfettered freedom,” they aren’t quite the Redmonkian kingmakers they might aspire to be. As big as public cloud computing has become, it remains a rounding error compared to overall IT spending. For most developers, most of the time, the CIO may be the “last to know” but they retain quite a bit of control/influence over developer decisions.

SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)

Small wonder, then, that Gartner analyst Lydia Leong can invest a fair amount of time advising clients on how to enable developer self-service, which sounds a lot like PaaS and, really, is PaaS, despite our weird resistance to calling it such. Perhaps one reason we resist the “PaaS” label is that PaaS failed to catch on, as David Linthicum has explained. Or maybe, as he suggested, a distinct PaaS no longer makes sense, given the cloud providers’ ambitions: “[T]he lines between IaaS and PaaS have blurred to near invisibility as AWS, Microsoft and Google continue to add features and functionality that fill the gaps between the two cloud computing models, particularly around app development.”

Regardless of what we call it, why are we talking about it again? Why haven’t we laid Heroku and Google App Engine and such to rest? Why do we persist in hoping that public cloud will go away, that “private cloud” can and should be a thing?

Because, as Google’s Kelsey Hightower noted back in 2017, “[T]he majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them.” In other words, they want cloud, but they also want to control that cloud. It’s this desire for control that keeps the PaaS dream alive. It’s what keeps driving even growth startups to keep rebuilding the cloud, over and over, in their image in the hope that somehow they’ll come up with a better AWS than AWS.

In the process, VMware’s Michael Coté argued, we keep creating our own custom clouds and big price tags to go with them: “Whenever you want to migrate to a new platform (on-prem helpdesk/ITSM to NOW SaaS), you put a (often shocking) dollar cost on too much customization.” Which invites 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 guardrails assembly required

As ever in enterprise IT, it’s a question of control. Or, really, it’s an attempt by organizations to find the right balance between development and operations, between autonomy and governance. No two enterprises will land exactly the same on this freedom continuum, which is arguably why we see every enterprise determined to build its own PaaS/cloud. Hearkening back to Coté’s comment, however, the costs associated with being a snowflake can be high.

SEE: The best serverless computing solutions (TechRepublic)

One solution is simply to enable developer freedom … up to a point. As Leong stressed: “I talk to far too many IT leaders who say, ‘We can’t give developers cloud self-service because we’re not ready for You build it, you run it!’ whereupon I need to gently but firmly remind them that it’s perfectly okay to allow your developers full self-service access to development and testing environments, and the ability to build infrastructure as code (IaC) templates for production, without making them fully responsible for production.” In other words, maybe enterprises needn’t give their developers the keys to the kingdom; the garage will do.

Timothy Loy Sutherland, Senior Director Cloud Enablement and Architecture at financial services software company Finastra, has offered a thoughtful approach to architecting guardrails 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 bespoke: “Standard infrastructure patterns, provided by the likes of Azure Kubernetes Service (AKS), for example, allow developers to build their services, regardless of the infrastructure or code language requirement, without requiring infrastructure knowledge and operational expertise.”

This is the happy medium that Redmonk analyst Steve O’Grady posited in a series of tweets. For O’Grady, crowning developers “kingmakers” isn’t about giving them absolute control to do whatever they want. But it’s also a counterbalance against absolutist IT policies that don’t allow developers to use preferred cloud tools. Citing the Netflix “paved roads” example, O’Grady called for “an IT-tested and backed core platform which is recommended.” Then, “if unique requirements force a team off that road, so be it, but then they’re on their own for literally everything.” Developers will presumably choose the “paved road” over paving their own. Everybody wins.

This is precisely what companies like Weaveworks try to do, as Weaveworks CEO Alexis Richardson explained to me in an interview. Weaveworks is intentionally multicloud (or, perhaps better put, runs wherever Kubernetes runs), so that the platform developers can choose transcends any particular cloud/operating environment, giving them even more freedom. Kubernetes can be notoriously difficult for developers because it lacks features like continuous delivery or observability we’ve come to expect from a platform. Weaveworks solves this problem by adding these developer-friendly features while making the platform open source, able to run anywhere. Enterprises get a standard platform but also one they can tailor to their needs. Customizability without the tears, if you will.

Yet we’re still not quite answering the essential question. As Coté put it, “‘PaaS’ as its own category makes sense if you FUD (real or just perception) on 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, a bit less dramatically, he explained, instead of FUD (fear, uncertainty, doubt), it’s perhaps better expressed as “reasons, actual or imagined, to not just use public cloud.”

Are self-service developer platforms, or the newest incarnation of PaaS, simply a way to hold off the inevitable future of public cloud? Maybe. But whether right or not, many enterprises aren’t ready to go fully cloud native and want to keep trying to balance the autonomy of public cloud with a bit of old-fashioned security and control. Or as AWS impresario Massimo Re Ferrè said, “Finding the right balance between ‘doing the right thing’ and ‘be innovative’ is incredibly hard.” Same as it ever was.

Disclosure: I work for MongoDB but the views expressed herein are mine.