Michael Coté, VMware: Developer platforms have been a thing for at least 10 years

You’re in a DevOps, wait, I mean SRE… nope, scratch that… “Platform Engineering” team. People are coming at you to get Kubernetes up and running and then build some kind of platform on top of Kubernetes. Kubernetes may be new, but building and running developer platforms has been going on for at least 10 years.

That’s how Michael Coté, a senior member of technical staff at VMware, introduces the talk he will deliver at the Main stage of the Shift conference titled Lessons Learned from 7 Years of Running Developer Platforms.

Are DevOps, SRE, and Platform Engineering the same thing?

Of course, the first question we had to ask him was a follow-up to his first sentence. Is DevOps dead or alive and kicking, and are DevOps, SRE, and Platform Engineering actually all the same thing? Michael admits even he is not sure:

“I go back and forth on this a lot. The sum total is helpful – they’re all espousing helpful practices and changes that organizations can follow and make to get better at how they do software.

It’s fair to say that the first wave of platform engineer thought leadership was harsh on DevOps, but I think that the early “DevOps is Dead” take has dissipated.

The platform engineering community is doing a great job promoting the idea of product managing platforms, the notion of a platform itself.”

PaaS is for platform-as-a-service

However, Michael adds that it isn’t exactly sorted out yet what platform engineering means. He admits being unsure if he’s even part of the core platform engineering community, so he has given up on defining terms strictly.

When pressed for the definition of developer platform, Coté says he defines it as “everything above IaaS, what we used to call PaaS.“

“For whatever reason, people don’t like to use PaaS anymore, but it pretty much perfectly defines what a “platform” is. I mean, it’s right there in the name of Platform as a Service.

You could also throw in developer tooling like CI/CD pipelines and the collaborative sites/consoles/dashboards developers use. Internal developer portals are another category figuring itself out). If those tools are tightly integrated with the platform to make building, deploying, and running the applications better, it’s probably worth including them in the definition of “platform.”

How platforms work at companies with thousands of developers

Platform engineering and developer platforms have been in the spotlight for the last couple of years, but according to Coté, they have been a thing for at least 10 years. They’ve come to the spotlight now because most organizations have finished their first round of putting Kubernetes in place.

“It took several years to figure that out and start seeing more use in the mainstream. Once you get Kubernetes up and running, you need to start building a platform on top of it: you have to add all that other stuff developers use.”

What Michael is particularly interested in is how big companies with thousands of developers and usually operating in pretty regulated industries have been running developer platforms in the last five, seven, or even ten years:

“Companies like Mercedes-Benz, JP Morgan Chase, several militaries, and others have been running platforms like those for 5, seven, ten-plus years.

What I like to do in my talks is catalog the practices they’ve learned over those years and what works and doesn’t.

I’m especially interested in what very large, usually 30 to 50 or more years old organizations are doing with their platforms: how they make it work for thousands of developers.

As a community, we tend to dismiss the wisdom of teams like this because they’re not using the next great technology. But, the ways to run a platform are pretty much constant over time, especially in larger organizations.”

The developer platform is a product; developers are your customers

One of the most important lessons he learned from working with such companies and their developer platforms for years is to treat the developer platform as a product. And develop it as any company would develop a product by gathering user requirements, developing what they want, getting feedback, and iterating on it.

If you want to have a good platform you have to immediately start product managing it and think of application developers as your customers.

Whatever team is building the platform should be talking with application developers all the time (weekly or so) and getting feedback on what works well for them, what doesn’t work, and if recent changes to the platform have improved things.

You’d think this is what operations people who run this kind of thing do, but they’re usually more focused on the state and status of the system – if it’s running, if it’s secure, etc., rather than the platform’s usefulness to developers.