Hey, here’s a question that I would guess has been discussed here before–I’d be happy with a redirect to previous threads if people have them. But… why has platform engineering become so much of a hot topic recently? Shared services and internal developer platforms have been around for a long time. Why is there such a spike in interest right now?

This is a pretty good article that I believe answers a similar question: https://www.honeycomb.io/blog/future-ops-platform-engineering

Old cynic me says there’s a “spike in interest” basically because there’s an entire industrial complex that makes its money on buzzwords, clicks, speaking engagements, etc. Like @Asaf Erlich says, it’s the same problems people have been solving forever… but there’s good money to be made in reframing those old problems over and over. _However_… while the problems aren’t new, I have over my career seen them come into better focus. My first job out of college (decades ago, now) was “building loads” for big telecom switches. The man who hired me (thanks Vinod, wherever you are!) said our objective was to automate ourselves out of a job. We were writing software, and that software had a huge effect on the product by speeding up dev cycles and reducing impact due to errors. But we weren’t looked at as “real” developers. I moved on as a software developer, but I was always less interested in making the product than I was in how I could make making the product better. I’m not a “10x” developer… but I’m a developer who helps teams of “10x” developers get all the way to “10x”, instead of getting bogged down in toil. I can have a big impact, and it’s a rush. But that impact wasn’t always very visible and it was usually hard to describe what I did. It didn’t really have a good title, and I sure wasn’t compensated like a “real” developer. Over time, the technology I used made incredible leaps in terms of the leverage it provided, but also increased in complexity. The industry started to recognize what I did as a sort of legit sub-specialty, and I rebranded as a “devops engineer”. It was a buzzword title, but it did make it easier to find people who needed my particular specialty. Of course, “devops engineer” has become too “low resolution” of a term, and now I see “platform engineers” and “developer productivity engineers”. I kind of like that latter one. I haven’t changed the essence of what I do, but the buzzwords and reams of “X is dead, long live Y” articles at least get folks in companies thinking about what I do as a legitimate, critical function. There’s always been a need for people like me; but there hasn’t always been a time when a CTO or VP of engineering recognized how much value I could add. All that to say: I don’t think it’s a spike in interest so much as just the emergence of better names and descriptions for roles we’ve always needed (and have always been building in one form or another). I’m thrilled this field is getting better attention, even if a lot of it is buzz and hype. The toughest challenges I’ve faced usually involved trying to find ways to get resources directed at improving the developer platform. If executives start taking platform engineering seriously because they read a hype article on Forbes.com… yeah, I’ll take it.

I agree with @Asaf Erlich that it’s an evolutionary shift that got a name. We saw a similar shift in frontend engineering over 15 years. Kubernetes gave people working on platforms a common language for talking about how to build platforms. This language now called Platform Engineering. Ultimately, the units haven’t changed, but we have ways to talk about them that is similar enough that we can create generalized, reusable and composable solutions.

Kudos to our friends at Humanitec for putting in a lot of hard work, effort, and money to generate the buzz. Buzzwords and hype don't make themselves.

@Ron Hough said a few things well. I'd say the growth of many tools under a single umbrella is driving this idea further. When you have an umbrella of hundreds of services in a cloud provider, new security, compliance, deployment, sre, monitoring guidelines the cognitive load to go from step a to step z is pretty massive.

All of this ^^^^. For another simple (and short) breakdown, Asim Razzaq's gives a non-buzzy version against the context of DevOps and SRE. https://podcasts.apple.com/us/podcast/ep-8-confused-about-platform-engineering-sre-devops/id1646310919?i=1000585420958

I’d agree with 90% of the above - the tech industry is fed by a news cycle, and that requires new terms. Putting the cynicism to one side, I’d say that “Platform Engineering” helps larger organisations deliver on the promises of DevOps at scale. And, you know, Kelsey Hightower called it in 2017 …

“I’m convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them.”

I've just joined this slack, so obviously I feel that Platform Engineer applies to me. Why? I just joined a startup and the CEO had no idea what my job title should be. After considering all the other titles I've had, I went with Platform Engineer. Not because I wanted something new and cool that Linkedin recruiters would go nuts for, but because my work is never confined to DevOps (which isn't really a job). And while I've covered SRE functions in the past, the companies I've worked for weren't Google scale, so that role never fully described my job either. Infrastructure/Cloud engineer/architect are sometimes closer to what I've done, but I've also gone way past building the infra.

Nice @Paul Rafferty! Cool to hear that startups are finding value in platform engineering practices. I'd be curious what you're including in your roles and responsibilities, and maybe even more curious about what you're not including.

Hey John! This is just my personal take, but I think the answer depends on the size of the company. In a startup, a Platform Engineer curates or builds the whole IDP, so their responsibilities are more inclusive, spanning traditional infrastructure and devops roles, with an added focus on overall cohesion (eg: providing something like Backstage and linking it to various systems, evangelising). A traditional DevOps engineer may not be comfortable building core networking or security, while an infrastructure engineer might not think it's their job to provide additional observability or IDP services. So I think the role "Platform Engineer" is more apt to assign to a seasoned engineer who can do all of the above. As a company grows, the functions of that lone Platform Engineer will expand, possibly filling a department. The teams within that department might end up covering very traditional responsibilities because of complexity at scale, eg: networking, dev tooling, observability. But the department as a whole maintains responsibility for the IDP. It's important that the "North Star" of the IDP doesn't get lost when people break off into those specialist roles. Someone senior is paying attention to current Platform Engineering practices, and is hooked into channels like this one.

Thanks @Paul Rafferty. That's a really good breakdown in a startup context.