What PaaS will mean in 2020

If you were asked to pick a theme for cloud computing in 2019 then you’d be spoilt for choice.

Would it be Kubernetes? It’s seemingly everywhere and, according to the Cloud Native Computing Foundation, 40% of enterprise companies are running it in production. Or how about Serverless? Its promise of lower costs and reduced ops burden have made it unmissable at developer conferences and on sites like this.

It’s neither … and it’s kinda’ both. As so often happens in tech, there’s a divide between the flashy projects people talk about at conferences and what teams actually do when they’re back in the office.

As such, 2019 has been as much the year of platform as a service –– PaaS –– as Containers or Serverless.

Not everyone has the same problem

For developer conferences to feel worth the ticket price, they have to tell big stories. It’s fun to hear how BigCo solved their unique problem. And, let’s face it, it’s also fun to imagine how we might do things differently.

But most application development is actually pretty boring. Boring in a good way! When done well, it’s about delivering value into the hands of users as efficiently as possible.

It’s tempting to look at the technologies that make headlines on websites like this and wonder how to get them on our resumes. However, technologies that work for BigCo might not fit elsewhere or, if they do, perhaps their overhead makes them impractical.

Take Hadoop. Six years ago, it was everywhere. Today, it turns out that Hadoop is really good for a small number of use cases but not so great at all the other things people tried to make it do.

And this is why PaaS makes so much sense as we leave 2019. Platform as a service offerings let us get value into production faster and easier.

Importantly, PaaS today is a much broader sector than you might expect.

How has PaaS changed in the past ten years?

Back in the early days, PaaS was all about creating no-ops deployment environments for web apps. Google App Engine served Python developers and Heroku served Ruby developers. The idea was to make code deployment as easy for developers of those languages as it was for PHP and ASP developers.

Today, PaaS has evolved in the same ways as software development in general. A fully-featured PaaS takes care of compute but also caching, scaling databases, security, third-party add-ons, and more. In fact, if we take the term “platform as a service” in its broadest sense then today that includes:

• containers-as-a-service: these focus on simplifying the operation of tools like Kubernetes
• full feature PaaS: like Heroku, these platforms provide everything necessary to get applications from merged pull request to production
• low-code: these platforms abstract away most hand-written code by providing a graphical environment in which developers specific data models, business logic, and UX and then deploy the resultant app to production.

As we head into 2020, platform as a service is the best way to get value into the hands of users, right from a complex Kubernetes cluster, through the development that’s familiar to most of us, to drag and drop visual coding.

PaaS is the natural end of the modern dev pipeline

Let’s focus on full feature PaaS offerings, as they solve the problem that most teams have.

The reality of devops is that it demands a tradeoff: deliver features that stakeholders need or take care of ops. But that runs against the grain of how most developers spend the rest of their time.

Typically, developers now spend their working day in an automated pipeline of commits, reviews, and deployments. That pipeline is about getting value into the hands of users as quickly as possible.

Managing ops is enabling work. It adds value where the requirements demand it but in a world where most applications require a pretty similar architecture, developer time is better spent delivering value to users.

What’s the point in an incomplete pipeline?

Think about continuous integration and continuous deployment. The guiding idea is to make code deployment less painful.

CI has us commit frequently, so it’s harder for unmergeable vectors to grow. CD automates the process of turning the merged code into something useful in production. Everything that can be automated is automated, until it comes to managing the VMs, containers, metal, or whatever the deployment target happens to be.

Imagine a smooth eight lane highway that runs beautifully before ending suddenly at a chasm. Teams aim to bridge that chasm with tools that automate dependency management, orchestrate clusters of containers, and handle configuration. Even if those tools automate some of the work, they bring their own ops overhead. If it’s not stretching our analogy too far, they act like a toll bridge after our smooth and free highway.

For PaaS, on the other hand, those are solved problems. The platform as a service route takes the CI/CD pipeline and extends its philosophy right into production. Developers focus on delivering value and the PaaS handles the details of marshalling compute resource, integrating with third-party services, running database clusters, and more.

PaaS is just how we do things now

For most developers building web and mobile applications, we do the job because we enjoy solving problems. But there’s only so much time in a working day.

According to Gartner, the PaaS market is going to double in size and it’s easy to see why.

In putting a PaaS at the end of our CI/CD pipeline –– whether that’s a Kubernetes platform or a PaaS such as Heroku –– we’re choosing to fix the problems that get features to market before our competitors, that ensure stakeholders see value sooner, that make a tangible difference in the world.

Pipeline image by Erlend Esketh
Rubiks Cubes image by Olav Ahrens