top of page

Creating a Bespoke Platform as a Service: History Doesn't Repeat, but It Often Rhymes

How do you create an internal developer platform (IDP) or platform as a service (PaaS) that supports self-service and is tailored to support your business needs, such as workflows, compliance, governance, etc., over the longhaul?

This is the key question for platform engineers, and I'm exploring this in an upcoming presentation. I'm starting by asking, "Why build a platform?"

Why build a platform (intentionally)?
Why build a platform (intentionally)?

If your team can answer these questions and identify the sources of pain (with baseline metrics) that you want to address with a platform, history provides many good lessons regarding your options.

No platform (a.k.a. YOLO)

Without an intentionally curated platform, there is no self-service, and every app/deployment/config is a snowflake. This is how I started my Java developer career in the 2000s. In 2024 there is a lot of amazing tech to bootstrap apps and infra now, and this is a good approach for many startups that just want to find product-market fit.

But for enterprise use cases, this doesn't typically scale beyond a handful of services.

Infrastructure (IaaS) platform

With an IaaS platform (think "access to the Azure console" and some guidelines in a wiki), there is self-service, but business needs are not implemented consistently. This is a dark side of the "you build it, you run it" approach championed by the DevOps movement.

You can get pretty far with this approach, but reacting to a Log4Shell incident or ensuring all your systems are PCI-DSS compliant can be super challenging.

Platform as a Service (PaaS)

With PaaS, you clearly get self-service (I loved “cf push”), but business needs are implemented in a generic or "one size fits all" way. And if you're using a SaaS-based PaaS, you often have limited control of the upgrade and deprecation cycle of the underlying platform (think AWS Lambda deprecating a runtime version)

Bespoke PaaS

If you can build your own PaaS, you can implement self-service and provide composable (and reusable) building blocks that support the team’s, department’s, and organisation’s business needs.

If you’re an old-school Java programmer like me, think of it as providing “aspects” (from AOP) for your platform. You are also in control of the upgrade and maintenance cycles across your fleet.

Next-generation PaaS frameworks are emerging

With the topic of platform engineering reaching the peak of inflated expectations, a lot of technology is emerging that aims to help engineers build platforms.

Referencing my earlier "why build a platform?" slide, always ask yourself if implementing technical solutions addresses your socio-technical pain points. DevOps taught us to value the theory of constraints.

I'm sure most platform engineers want to enable their organisation to:

  • Go faster: Platform teams need to provide “everything as a service” to help rapidly and sustainably deliver value to end-users

  • Decrease risk: Teams need to automate manual processes in reusable components

  • Increase efficiency: You need to manage and scale your digital platform and resources as a fleet

Once you have your goals and pain points identified, there is a range of technology to explore (and I'm obviously biased towards Kratix!).

Emerging platform and PaaS tech stacks
Emerging platform and PaaS tech stacks

Everyone wants a PaaS, but...

As Kelsey said in 2017, we all want to build our own PaaS, but maybe now this is a reality for the majority of enterprises...

Kelsey Hightower sharing wisdom on creating a bespoke platform
Kelsey Hightower sharing wisdom on creating a bespoke platform

Join me in London in June to explore these ideas!

I'll provide my take on these technologies in a future blog post, and I'll also be discussing these ideas in person at the following events:

65 views0 comments


bottom of page