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?"
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.
This is why I'm bullish on the recent development of platform frameworks and orchestrators.
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!).
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...
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:
Atlassian's DevEx & Platform Engineering Meetup, June 6th
AWS's Building the ultimate developer platform, June 11th
Коментарі