How to Build a PaaS, Part 1: So, I hear you’re planning to write a PaaS

Part 1 of “The How To Build a PaaS Book”

So, I hear you’re planning to write a PaaS..

You’re about to embark on a challenging and exciting adventure — I’d love to see if I can help?

This book (series of blog posts) is your (I’m saying this before even having written it — that’s how confident I am) indispensable guide to everything you’ll need to succeed in building a platform as a service.

Yes really! Pull up a chair. Brew some coffee. Toast up some crumpets. Let’s get started.

Who are you why are you writing this?

My name is Julz, and I love PaaSes. (Hi, Julz..)

I worked (and still work) on one of the most popular PaaSes — Cloud Foundry — for about five years. I’m pretty passionate about the value of PaaS: I really believe that if we’re still worrying about the low level details of containers and patching and operating systems and ReplicaSets and Deployments and nodes and taints and StatefulSets and pods in 5 years something will have gone horribly horribly wrong in a really sad way.

Of course, there’s an elephant in the room: the Cloud Foundry community’s general pitch has always been “don’t write your own PaaS, use this”. So why am I now about to spend lots of time laying out exactly how I’d go about writing my own PaaS?

Well, regardless that CF is pretty great, many people still want to write their own PaaS and, what’s more, building a PaaS is fun!. There’re some really interesting decisions to be made, some really great technologies to learn about, and — hey — maybe we could even get lucky and build something useful.

Plus a few folks suggested I do this so it’s their fault.

Please commit to a series of chapters.

As this is the first in a series of posts, here’s a rough outline of the rest (I’ll update it with links as I write the actual content!):

— One: So, you’ve decided to write a PaaS (this post you’re reading now)

— Two: All about UX. (How to choose a developer experience, what makes a PaaS a PaaS, is writing your own really a good idea?)

— Three: From Code to Containers. (Options for taking code, making containers)

— Four: Orchestrate This. (Choosing and Using a Container Scheduler)

— Five: Dealing with State. (Services, the Open Service Broker API, Volumes and Persistent State)

— Six: Routing (Shared routing, distributed routing, envoy, itsio and route services)

— Seven: To Your Good Health. (Figuring out Health Management and Fault Tolerance)

— Eight: A Tale of Scale. (Autoscaling and just plain scaling, also a bit about billing)

— Nine: Log a Rhythm. (Streaming app logs and metrics)

— Ten: Patch Me If You Can. (Keeping stuff patched, because security m’kay?)

— Eleven: Orchestrating the Orchestrator. (Options for deploying yoru orchestrator and keeping your orchestrator healthy).

— Twelve: Putting it all together.

Let’s Begin

This will be a practical series, but it’s also going to be avowedly non-prescriptive (I just avowed it). Each chapter (post) will survey the popular approaches and tell you the pros and cons of each of them. We’ll do a deep dive in to the most popular ones and build some example code. At the end, if you want to, you’ll probably be able to build your own PaaS, but even if you choose not to (and you should probably choose not to) I promise understanding the options and technologies will help you understand which off-the-shelf solutions are best, and how best to exploit whatever solution you do end up using.

So let’s go. (Next time.)

Like what you read? Give Julian Friedman a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.