I am super excited to read the first two chapters of Platform Engineering by @skamille.

I'll be leading a little book club at work this week. Tonight is the last night I can reasonably prepare, so I'll be live tooting my hot takes as I read through the first two chapters to prepare myself to facilitate discussions.

Platform Engineering

Until recently, infrastructure was the backbone of organizations operating software they developed in-house. But now that cloud vendors run the computers, companies can finally bring the benefits of agile custom-centricity … - Selection from Platform Engineering [Book]

O’Reilly Online Learning

I like the framing of platform engineering as being somewhere between chaos of free-for-all (no-ops) and a fully centralized ops team.

I tend to think of it as a different way of offering centralized tooling. It's not just the way the platform team works, it's also about how the organization operates around the team.

I am thankful to work in an organization that empowers teams, so our platform engineering team works very close to how @TeamTopologies describes a platform team.

So far, so good! I'm excited to read more. 😽

@kelseyhightower is a gem and I love his quote in the praise section.

Oh good, there's a "how to read this book" section and the reading schedule I arbitrarily decided just happened to line up with what is recommended. 😅

I love when books have this; especially when I'm doing a book club. It's nice to have a "you should understand TOPIC at a high level by the time you're done."

ha the first chapter is like "maybe skip this if ur already a platform engineer", nice.

I love fundamentals, though. I watched old SICP lectures every year for the first 6-7 years of my career to keep my fundamentals sharp.

Fundamentals are so important and far-reaching, so I really like to revisit them and keep them sharp.

"Platforms achieve leverage in two ways: making applications engi‐
neers more productive [...], and eliminating duplicate work"

That's how I've always conceived of it. I almost always find myself on the "eliminating duplicate work" team. Doing boring import stuff that needs doing.

Fun note here, at Grafana we have a Productivity squad on our platform team! The rest of our squads are more focused around eliminating duplicate work - mostly operational toil.

I worked with a manager once who very crassly said "some operations engineers just don't have the product gene."

I don't really agree that some people are inately good at product development, but I have certainly experienced this. Getting some folks to think about operations tooling as a product... can be hard.

I have found it to be a real challenge on Network squad. How do you deliver a subnet as a product? It turns out it's actually quite simple, it just requires a minor shift in thinking. The best way I have found to get teams to buy in is to focus on testing and releasing. These are important justifiable things and will result in producing requirements and success criteria which naturally lead to changes being released as a product.

Thankful here again to work on an incredible team of Platform engineers who just get this stuff.

Wow, 60-75% of costs of software come after development. That's not really surprising, but I am really excited to highlight that number.

The he topology of the ideal platform in this is exactly how I have always done operations.

My first ops job had a bit of old school methods from ye olden days, but we moved to a platform as quickly as we could. That's pretty neat. I've been doing platform engineering for quite a while now.

Most of it has been with Kubernetes, but job.prev had a really neat python based lambda thing for deploying clusters of EC2 infrastructure. When I started building my own version of Crossplane, I decided it was time to go Kubernetes there too... but I will admit that I miss that old platform. It was so simple and quaint, yet incredibly powerful and flexible.

Biting my tongue about the strict definitions of terms...

Fascinating stuff about SRE being portrayed as a failed idea. I haven't really heard it described that way and I can think of a lot of things I have learned from SREcon or the SRE books that I make use of in my platform engineering...

I agree that SRE was not a silver bullet, though.

Still, it holds a lot of truths. Keep the error budgets and leave the chaos engineering.

Let's be real though, I fucking love chaos engineering. I would absolutely kiss a bearded author who has published papers on lineage driven fault injection.
Oh no, this book is making me rethink how I was framing the WAF project I am involved with... I thought I finally had a clear picture lmao

You can build a platform out of:

  • Terraform (yes, really)
  • Code (Python, Go, Rust, etc)
  • Kubernetes + YAML ... so much YAML
  • jsonnet
  • bash (please don't though)
It's not the technology choice that makes a platform. Don't let anyone tell you otherwise.
"Making smart choices about when to push people toward central offerings and when to let them spin out their own alternative “shadow platforms” is a key skill for platform engineering leaders" 👏🏼
Goddess I am glad we have Backstage. It's so good.
@terracorp would love to see who uses backstage, as in which people within an Engineering org use it at least once per month for at least two consecutive months, I suspect the list is very small.