PaaS, BaaS and what’s next

In my last post, I posited that backend development is now backend service development, and I questioned if we should be using the same tools and processes to build services as we did for monolithic web apps.

If we’re going to pull on this thread, we need to look at the intersection of backend services and the cloud, where we’ll find Platform-as-a-Service (PaaS) and Backend-as-a-Service (BaaS).

Not long after Ruby on Rails caught everyone’s attention in the mid 2000s, early PaaS offerings such as EngineYard and Heroku were launched. Personally, I wasn’t too familiar with PaaS at the time, but while working at Red Hat, I began to take the cloud a lot more seriously after the release of OpenShift (Red Hat’s PaaS).


The mid 2000s also gave us a reimagined Battlestar Galactica, and it was amazing (up until halfway through the last season anyways). Oh, and the decade started with new albums from Tool, System of a Down and Slipknot.


I would argue PaaS predates microservices and was intended for the monolithic apps of the day. However, PaaS offerings continue to provide devs with a great deal of flexibility – they can deploy anything. Further, PaaS offerings tend to support a broad range of backend components – from standard SQL databases to NoSQL and time series databases, in-memory caches,  full-text search engines and message brokers. And often support multiple environments with CI/CD pipelines.

The downside is devs have to build all of their services from scratch, including generic ones for CRUD and authentication. These services are not unique. They do not provide the business with differentiation or a competitive advantage. However, they still take up valuable dev time.

Fast forward a few more years and I took note of Backend-as-a-Service (BaaS) offerings such as Firebase and Parse. I was working at Couchbase, and we were beginning to market Couchbase Mobile. From our perspective, right or wrong, the demand for BaaS offerings was coming from mobile app devs. The only thing they needed to launch their mobile app was a cloud backend. Today, I would say it is coming from frontend devs. There are a number of cloud platforms for building and deploying web frontends, and like mobile apps, all they need to go live is a cloud backend.

BaaS offerings, in a sense, are simply databases with a layer of CRUD services on top. They consist of a database, REST and/or GraphQL services, authentication and authorization, file storage, and to varying degrees, support for custom serverless functions.

The upside is devs get core services out of the box, and they don’t have to worry about infrastructure. However, that’s all they get. BaaS offerings don’t let devs deploy a message broker or stream processor, and there is no way to insert business logic. While serverless functions are helpful, support for them is clunky at best. And support for multiple environments is either crude or non-existent.

PaaS provides devs with flexibility, BaaS provides them with a shortcut.

What if we could have both?

What if there was a cloud platform designed with services in mind, rather than monolithic web apps?

I believe the market needs a solution that closes the gap between PaaS and BaaS.

It should support lots of different backend components like a PaaS, but provide a bunch of optional services out of the box like a BaaS.

Stay tuned for my next post as we continue to tease out what it is we can do to make it easier and faster for devs to build and deploy backend services.

P.S. – I’ll make sure to get it posted before the 5th season of Cobra Kai starts in two weeks.

Get great content updates from our team to your inbox.

Join 86,000 subscribers. GDPR and CCPA compliant.