"Platform Engineering" is rapidly becoming the new DevOps or SRE. Almost every day we hear about another org building an internal developer platform or control plane.
Want to know what platform engineering is, where the trends are going, and why you should care?
Read on 🧵👇
We've all been building application/web platforms for years
- On-premises: ticket-driven, bare-metal, long lead time
- First-gen PaaS: self-service, VM-based, one-size-fits-all, on-demand
- Next-gen PaaS/Custom platform: self-service, container-based, fast feedback, good UX/DevX
The rise of more ops-savvy developers (and SREs) and developer-friendly infra tooling has led to a boom in the creation of custom platforms
The attraction to building a custom platform is that you can craft the abstractions to match exactly what your org requires (in theory)
This concept of "platform engineering" first crystallized for me when listening to the @NetflixOSS team talk in the mid-2010s about how they had created an internal developer platform and supporting toolchain
A big focus for them was providing a "paved path"; a developer-focused, low friction, and ops-supported platform (and supporting processes) that allowed Netflix engineers to ship and run apps quickly and safely
In the future, they elaborated on the enabling concept of "Full Cycle Developers" that worked in symbiosis/harmony with the platform engineering teams -> netflixtechblog.com/full-cycle-dev…
Simultaneously, Google was talking a lot about SRE. There is a lot of cross-over between platform engineering, SRE, DX teams etc, as noted by my colleagues @rdli and @bjorn_fb :
The common thread across roles: focus on eliminating toil for engineers
Of course, platform engineering is not just for unicorns 🦄. In this recent @a16z blog post, @jeanqasaur argues this perfectly and states that we should be building tooling and platforms for the "99% developers"
These "real developers", or "dark matter developers" as @shanselman calls them, work in your org. These are the folks that you should be building platforms and tools for
Bottom line: recognize that you're probably not Netflix, Google, et al, and design your platforms accordingly
My key takeaways here: always listen to your platform customer (developers); and the only way to succeed with platform adoption today is via a "bottom-up", developer-led, approach
Based on my past experiences as both a software developer and platform builder, I see an increasing need to focus on developer experience (DevEx/DX) within the domain of platform engineering
I explored this more in a recent @KubeCon_ NA DevX Days talk ->
I'm definitely standing on the shoulders of giants here, and at the same conference @gojasmineee delivered a fantastic keynote on the subject of "Creating a Holistic Developer Experience"
Along with a focus on developer experience, platform ownership is a core concept. I've learned a bunch from @phennex and the Lunar team about this over the years e.g. getambassador.io/developer-cont…
Key takeaways here: "enabling developer ownership is key to speed and safety"
And if you're looking to avoid the common mistakes when building a platform, this piece from the @humanitec_com team is a great jumping-off point -> humanitec.com/blog/top-10-fa…
Changing gears, this breakdown of @HashiCorp's S1 by @edsim provides a lot of insight into this space, too. In the goldrush of platform engineering, HashiCorp are selling very popular -- and very effective -- picks and shovels
Some of the key themes that Ed picks out for platform product/component builders also applies to platform engineers creating internal platforms and developer control planes:
- Must win the hearts and minds of developers
- Open source matters
- Design/UX matters
Key themes from his most recent Developer Led Landscape:
- Any Developer With An Idea [is empowered to execute]
- Power Shift From CIOs to Developers
- Dev Empowerment Drives Emergence of Product-Led Growth Companies
The future of platform engineering is bright, but we mustn't forget the fundamentals: we're all here to deliver value to our end-users customers; a platform can help or hinder with this -- treat your platform as you would any other product in your org
I'll wrap up this thread with a great recent chat I had with @alanmbarr, platform builder at @veteransunited. If you're looking to build a business case for creating an internal developer platform or platform engineer team, this is the article for you: