"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

infoq.com/news/2017/06/p…
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 :

blog.getambassador.io/the-rise-of-cl…

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"

future.a16z.com/software-devel…
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
And this is a great Reddit thread on the dangers of getting this wrong -> reddit.com/r/devops/comme…

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"
If you're looking for an intro piece into the history and future of platform engineering, this recent post from the @software_daily folks is great -> softwareengineeringdaily.com/2020/02/13/set…
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

whatshot.substack.com/p/whats-in-ent…
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
And check out @TylerJewell musings: tylerjewell.substack.com/p/developer-le…

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:

getambassador.io/developer-cont…
I hope this thread was useful! If so, please let me know, and feel free to share your experiences of platform engineering 🙏

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Daniel Bryant

Daniel Bryant Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @danielbryantuk

Feb 13
My top 8 commands and tools for debugging applications running on @kubernetesio 🧵👇
A good first step is viewing the app's pods and associated logs (potentially targeting a specific container) looking for obvious crashes

$ kubectl get pods -n my-namespace

$ kubectl logs my-pod -c my-container

More info -> kubernetes.io/docs/reference…
If a container gets stuck in a crash-loop-backoff, use the `logs --previous` flag

$ kubectl logs my-pod -c my-container --previous
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

:(