To PaaS or not

PaaS or what?

Over the last year or so there have been many good discussions on “tech twitter” around the topics of IaaS/PaaS and how its time to reinvent Heroku. So many conversations, that I have lost track at this point. While some are on exact topics of PaaS, decline of heroku, the others are tangents or branches that talk about overlapping concerns like - why move out of Heroku? How do you get good CI/CD with your own PaaS? What about on-prem? and the list goes on.

Anecdotally, I think there are also a lot of founders or potentials founders testing the waters and trying to think ahead on the next breakthrough which is creating this perception of needing a PaaS that is not Heroku. Ofcourse also combined with Heroku is also not a one-size fits all.

I think Heroku will always have a special place in a developer’s stack. Heroku is extremely good at what it does. Its still a goto for so many early stage companies. Despite public cloud having similar-ish things.

So why do we keep revisiting these topics? I think there are a few ways to go about this

• Experience: Engineers who used Heroku but are no longer able to because their team/company moved to public cloud. They now miss that magical Heroku experience.
• Cost: Heroku is expensive. Render.com is really good alternative IMO, and love what they are doing, with their plans on being their own cloud IIRC.
• Feedback loop: The current process, tooling is just not good enough and/or the feedback loop for faster iteration is too high for software development teams.
• Feature parity: Software development teams are now on public cloud with their company having a dedicated Infra-like team but these teams are not able to move fast enough for feature parity while keeping the lights on.
• Abstractions: There is a growing appetite of creating higher level abstraction over Kubernetes, ideally the customers to these would be the software development teams who are looking to move fast for their software development workflows. The caveat being - figuring out the right level of abstractions.
• Hiring: For early stage companies - they don’t want to hire specialist talents like DevOps/SRE early on, if they don’t have to.

So how do you give your software development teams a seamless experience for deploying and managing their full stack applications, while still having enough control for customizability for unique workload requirements or when the workloads mature over time?

Future

I don’t have the right answer but I have been noodling on this in my free time since late 2019s. I really don’t think the technology is the hard bit here (while complex and sophisticated but not a blocker). In fact there couldn’t have been a better time to build something like this with Kubernetes, Cloud Native offerings and such strong community support of CI/CD abstractions. I think roughly what it comes down to is:

• Creating a high level abstraction over Kubernetes that caters to the “happy path” of SDLC that feels like a rich Heroku like experience.
• Having an opinionated way to design, develop & ship full-stack applications.
• Adopting a Platform Mindset. This is key because the platform itself needs to scale as the applications scale alongside people, process and growing requirements. Otherwise you run into the same issues as with Heroku where after a certain point you start to veer off of that path.
• Decoupling build from deploy & release processes. Extensible enough to hook into modern CI systems with good enough defaults for build, deploy & release pipeline stages.
• Support for sidecars or “Add Ons”. Engineers like chefs love their tools, make it easy for them to bring their existing tools & favorite vendors.
• A product first approach. A product and platform mindset is key IMO. I think AWS got the latter part extremely right (amongst many other things ofc).
• Supporting commonly requested features like Preview Environments (on demand virtual envs on every git push), Blue/Green deploys, good micro-services support and so on.
• There is no one size fits all. Not worth trying to solve for every unique workload type.

Just imagine - Bringing in your codebase from Github, providing start & build params for your application, hook it with your choice of DB/Cache and off you go. Most common operations are managed and infrastructure provisioned behind the scenes, with infrastructure being managed as code.

Whats next?

There are a lot of workloads for which creating these abstractions would be the hard part and thats what I want to figure out (where does this break).

As an engineer/IC I think there is a lot of worth to solving these problems. The conversation revolving around PaaS or Heroku doesn’t seem right to me. Its a good example and use case for inspiration but not as a guiding heuristic. I would love to build this vision I have in my head for my fellow software development teams and helping them deliver with velocity. Its an active conversation I keep having with folks in industry and at my current workplace.

As a builder I don’t think every modern software development company should have to build the same thing on & on. A higher and more opinionated solution should be able to solve majority of these cases, but not all. As it turns out - there is plenty new comers in this space (maybe 3-5 in the last few batches of YC itself).

I have been hacking on this on the side for a while now to see how scalable this really is in terms of practices, processes and tech. Mostly scratching an itch, exploring new technologies and writing full stack code (all the way from CSS to IP Tables) 🙂. If you are interested in jamming on this, hit me up (twitter DMs are open). I plan on open sourcing it at some point.