You might be building a PaaS if…

We just opened a time capsule from 2003 and couldn't believe what we found. An AOL CD-ROM with 2,000 free hours; a Dell blade server chassis; and a Blue Collar Comedy Tour DVD. We couldn't install AOL, the blade server power supply was dead, but our Blue Collar DVD works just fine. We were reminded again about Jeff Foxworthy’s “You might be a redneck” skits as the star of the show. So we channeled our inner blue collar comedy and applied it to container orchestration—because, hey, why not?

If you rewrote 20 Amazon CloudFormation scripts last week...you might be building a PaaS

It’s not 2003 anymore, but it was way easier back then to know what you had running. You couldn’t spin up new clusters and configurations. Your server literally existed in meatspace or it literally didn’t. Today in 2023, you’re spending hours rewriting CloudFormation scripts provisioning servers like a jackhammer. Every. Damn. Day. Just before you punch a hole through your monitor, you import (or write) a tool to handle updating the scripts. Before you know it, you’re on your way to building a kickass PaaS that’ll work until next week.

If you need to learn a new kubectl command every day…you might be building a PaaS

Remember destroying all those little aliens hopping on the screen in the game Space Invaders? Managing k8s clusters can feel a bit like that. Applications and services keep showing up in new clusters, eating resources. And it’s your job to shut them down before everything’s out of control. 

So you download kubectl to control your Kubernetes clusters. And then helm. Then kubectx and kubens and stern and k9s and bootkube and ktunnel. Oh, and Kops. Then maybe monokle to see how that goes.

Soon you’ve got more tools in place to manage your Kubernetes infra than domain names you bought last new years eve. Maybe it’s time to buy a ream of paper for all the pages you’ll need when you print out your “kubectl cheat sheet” - or the docs for what might as well be your new PaaS.

If you find yourself checking to see if there are any updates to Heroku you want to copy…you might be building a PaaS

Hate Heroku, the great grandaddy of PaaS? When you started out with Kubernetes, you took a look at Heroku and rejected it because it wasn’t cool anymore or because some DevOps engineer laughed when you suggested the idea. More realistically, you probably felt like it was too much of a black box. If Heroku didn’t support it, then you were stuck. No flexibility. 

But now that you’re building out your k8s you’re finding that you’re boxing yourself in. Maybe Heroku has a feature you really would like to use. Maybe you can copy it? Maybe Stack Overflow has the answer. Maybe you’re building a PaaS after all?

If you find yourself chasing the perfect service catalog (that devs will refuse to use!)…you might be building a PaaS

Building a service catalog is a necessary evil. You need rigor, you need documentation, you need maturity and management. Most of all, you need your dev teams to use it.

But let’s be honest: they won’t. Deep down in your heart of hearts, you just know they’re going to tear it down in some backchannel Slack discussion or subtweet (sub-X?) you.  

The more you perfect it, the more you hear that it’s not ready. It’s finally dawning on you that it’s *never* going to be good enough for them. But you are so far into your sunken cost that you haven’t realized that you’re halfway to building a PaaS.

If you’re building a Cloud Platform team instead of your product…you might be building a PaaS

NOW HIRING: Engineers who can build a platform for engineers who can deliver value to the market.

Getting your cloud platform right is the secret to getting your product right—running smoothly, scaling up (and down) just as you need. It’s so easy. Just get a few cloud-native DevOps engineers on staff and you’re golden.

The actual problem? There’s a talent shortage. Everyone from TSMC to the donut shop around the corner is dealing with it. It sucks. How are you supposed to get your PaaS-like-but-totally-not-a-PaaS provisioning and orchestration platform up and running?

If you’ve used the words “developer experience” when talking about building tools for you infrastructure…you might be building a PaaS

It started so simple. A little JIRA request, a little Cloud Formation templating, a little auto-generated YAML—you were off to the races. You built it at a hackathon. It was going to change the future of the company. Then one of your devs said, “The developer experience around this needs to be better.”

You’re thinking, “Be better? Are you kidding me? I built this in 4 hours with nothing but a bowl of spicy Takis and a 6-pack of Liquid Death. I’m a genius. You should be worshiping at my feet right now.”

Besides, wtf is a “developer experience?” We’re building tools for kubernetes. We’re lucky to even have me here to be orchestrating all this. You don’t like it? Go build your own platfor–uh, service.

If you’re building internal docs and runbooks to keep your services running…you might be building a PaaS

You wrote the main page. That should be good enough, right? Nope.

These cloud services are getting complex. But what’s the limit? How many edge cases do you need to describe? How much do you need to write? You find yourself adding more and more background and pointers to platform docs just to get your team up to speed. The devs keep saying the docs need to be clearer and add more context. You might as well be writing Kubernetes for Dummies. Wait—that’s actually a good idea!

Have you considered not building a PaaS?

Obviously, this is all in good fun, but if any of this sounds remotely familiar, you gotta ask yourself: What are you doing writing all this stuff? It’s a solved problem. Like, okay, Heroku may not be it anymore. But is there really nothing out there that can solve your Kubernetes problems in the 2023rd year of our lord? It’s not just the time you’re spending. It’s also the cost. Build vs. buy is what they say. If you don’t have a really good reason to build then take that money you are spending on building and just buy a solution. Done.

Of course there is. I mean, there’s a freaking Hannah Montana Linux distro out there. Why wouldn’t there be something that fixes cloud provisioning and orchestration?

Listen, we’re not saying you need to try Aptible… but you should probably try Aptible.