Even as Amazon Web Services was ascending to a position of market dominance in the exploding category of Infrastructure-as-a-Service (IaaS) – a category, notably, that it created – and added new features and services at an improbable rate, there was one area in which the company pointedly did not invest in. While few remember this today, Platform-as-a-Service (PaaS) technologies debuted shortly after IaaS, so the categories are of roughly equal age. While the IaaS market took off, however, PaaS languished until standardization arrived via service providers such as Engine Yard or Heroku, and later the arrival of open source implementations such as Cloud Foundry and OpenShift.
The lack of initial adoption explains AWS’ early reluctance to target the PaaS market outside of specialized instances such as Elastic Beanstalk. Their continued lack of native participation in the market was more curious, given AWS’ stated interest in the enterprise market and the obvious functional parallels between the classic middleware buyers loved and the emerging PaaS offerings.
“When will AWS get into PaaS?” then became a common question, amongst analyst and media types if not the developer populations that AWS courted. This remains a relevant question, even if the term PaaS itself was deprecated along the way.
It could be argued, however, that AWS has already answered that question.
Much as PaaS was a logical functional successor to middleware, serverless can and has been argued to be the new PaaS. It’s easy to get wrapped up in the functional distinctions, because serverless functions are built in a fashion quite distinct from more traditional PaaS applications, let alone their middleware ancestors. But if we zoom out, the long arc of application development evolution is more about layers of abstraction than execution models. In that sense, serverless can be seen as a logical next step after what used to be called PaaS.
If true, this means that AWS has had, in effect, a PaaS offering since 2014. Like PaaS, the tradeoffs it imposed initially for developers led to slower adoption than might otherwise be expected, but once acclimated and assured of some measure of portability from environment to environment, adoption has accelerated.
If AWS intended to offer customers a choice between full control infrastructure and hermetically-sealed, no effort alternatives – what we once called PaaS, you’d expect to see them Lambda all the things. Which, at reInvent this past fall, is exactly what they did. From the introduction of an app registry to pushing Lambda into everything from core databases to the edge, AWS is signalling its commitment to both the serverless model and its product instantiation of same.
In doing so, AWS is effectively deciding, for its customer set at least, that serverless is the new PaaS. Customers that prefer granular control can and will continue to invest in infrastructure primitives. Those that are willing to sacrifice control in return for reduced operational responsibility, on the other hand, are being implicitly directed towards serverless models and products.
Whether or not serverless is the new PaaS seems like an academic discussion, but it actually has serious implications for customers and vendors alike.
For one, it reduces AWS competitors’ ability to outflank the cloud giant via abstraction. Given the difficulties out out-performing an established incumbent in their core market, many AWS competitors should have been considering opportunities like serverless to island hop via layers of abstraction. AWS offering that natively, across a wide variety of services, limits the effectiveness of such an attack.
For another, should widespread adoption of serverless occur, the implications for application development are significant. Much as cloud native applications are built in a manner that differs from traditional middleware applications, serverless applications are a yet another departure from traditional application development models. Which means that developers will face widespread learning curves, and potentially more problematically, existing development platforms will have to adapt themselves to a very different environment.
Questions of application portability will also become paramount. The prospect of single environment applications killed the first generation of PaaS offerings for developers concerned about lock-in. Conversely, it’s been argued that lock-in is one of the reasons Google released Kubernetes; Kubernetes was a tactic to ensure that the container category did not get welded to AWS infrastructure permanently. What – if anything – will emerge as the Kubernetes for serverless workloads? The space is crowded at present, with everyone from Kubeless to OpenWhisk to Serverless throwing an oar in.
To be clear, serverless is not the once and future application development paradigm. As my colleague described this week, development is very much a spectrum, and serverless merely one point on that spectrum. But it seems clear that if AWS has anything to say about it, serverless will become the preferred approach for PaaS-style functional requirements.
Given AWS’ size and speed, they will have a lot to say on the subject, which is why everyone needs to pay attention to what otherwise might seem like a simple question of terminology.
Disclosure: AWS, The Cloud Foundry Foundation, Engine Yard, Google, Salesforce (Heroku), and Red Hat are RedMonk customers.
