The Details: Platform as a Service (PaaS)

Honoring our late friend, Heroku, may its memory be a blessing

Greetings, my loyal and industrious paid subscribers. This week’s post is going to cover PaaS, a word (acronym?) often used but rarely understood among non-developers (and frankly, even among developers). We’ll dive into what PaaS is, what distinguishes it from IaaS like AWS EC2, and why a developer would pay extra – a lot extra – for what appears to just be scheduled upgrades.

The most recent deep dive post for paid subscribers covered APIs and databases together. Check it out if you haven’t yet! And if you have an idea for a deep dive topic, just send it my way.  

Platform as a Service and how developers deploy their code

Imagine you’re a software engineer at an early stage recruiting startup (this could be you, mon frère). You’re working on the first version of your app, and you have something pretty decent running locally on your laptop. You want to set it up on a server somewhere, behind a URL, so you can start testing it with a few early users. It’s a pretty simple app with a database and a few APIs for now: it doesn’t need Kubernetes or anything fancy, just a run of the mill server. What are your options?

Infrastructure as a Service – IaaS

The standard, and most straightforward option, is to use one of the basic multi-tenant server options from a cloud provider like AWS. One of AWS’s oldest and most popular products, EC2 allows developers to get a server up and running in no time. Once you figure out how to access it from your computer (via SSH or otherwise), you basically just have a terminal staring at you.

To turn that terminal into an app, you’ve got a lot of work to do: DNS, cloning your code, upgrades, networking with other servers (i.e. database), monitoring, redeploys, debugging manually via logs, and a lot of other fun stuff. We’ll go deeper into what this experience looks like in the next section.

Platform as a Service – PaaS

With PaaS, the experience is significantly simpler. Instead of setting up a server and installing + configuring everything on that server, you just point the service at your code (on GitHub or elsewhere) and it deploys the code for you. Any other configuration – DNS, networking, scaling, you name it – happens through the PaaS’s nice UI. You get automatic charts, system upgrades, searchable logs, and deploy history without any extra work. It’s quite lovely.  

The OG PaaS – the one that made everyone realize that this was obviously the way to do things – was Heroku. They (sadly) were acquired by Salesforce in 2010, which has all but destroyed their business. And developers are sad about it. We’ll go deeper into the Heroku / PaaS experience in the next section. 

Serverless

If you don’t want to deal with any servers whatsoever you can deploy your app as a series of separate functions on something like AWS Lambda. This is not a popular option yet for substantial apps, but you can read more about it here.

Some other options

It’s impossible to keep up with the myriad of options that startups are concocting for deploying your apps, and this section exists solely so I don’t get called out for missing one of them.

The IaaS experience vs. the PaaS experience

Let’s walk through what it looks like to get my code up and running on bare metal (IaaS), vs. what it looks like to get my code up and running on a PaaS. The application lifecycle is long and tedious, but even the setup process can be illustrative as to why people like PaaS.