Luca is the Core Contributor to PlatformEngineering.org, the world’s largest platform engineering community with over 200,000 members. He routinely speaks to dozens of engineering teams every month, and summarizes his learnings and takeaways from hundreds of setups into crisp, insightful content for everyone in the industry, from beginner-Ops to cloud experts. He is the host of PlatformCon, the world’s largest platform engineering event, and writes to over 100,000 engineers every Friday in his newsletter, Platform Weekly.
Is Platform Engineering just rebranded DevOps? Can you do Platform Engineering without Internal Developer Platform? And, the biggest question of all, what even is Platform Engineering?
In this episode of the Hangar DX podcast, Ankit tries to find answers to those questions with Luca Galante, Core Contributor to the world's largest platform engineering community, host of PlatformCon and the author of PlatformWeekly.
Luca says that if it weren’t for AI, Platform Engineering would be the hottest trend in the software industry right now, so let’s start by answering that question first.
What is Platform Engineering?
Luca admits that a lot of people hate the term Platform Engineering because it can mean a hundred different things. His definition is:
Platform engineering is the discipline of designing and building toolchains and workflows that create golden paths for developers, enabling self-service capabilities and shielding them from underlying infrastructural complexity. The sum of those golden paths is the Internal Developer Platform.
Why does platform engineering exist?
Luca answers that question by looking back at what software engineering was like a couple of decades ago. If developers wanted to get anything done to run their applications, they would have to throw their code “over the fence”, which led to poor experiences on both sides of the fence. As an industry, we all agreed this was not the ideal we should aspire to.
Some 15 years ago, DevOps gained ground and established itself as the new golden standard for engineering teams. The pendulum swung back to developers with the ‘You build it, you run it” philosophy. Suddenly, engineers had to master 10 different tools just to deploy and test a simple code change
Organizations realized that this approach doesn’t work and that they can’t expect every junior frontend engineer to onboard to increasingly complex infrastructure.
Platform engineering teams build IDPs, which is a layer between ops and developers. When using these IDPs, developers can pick the right level of abstraction to run their apps and services, depending on their preference.
Is Platform Engineering just a rebranding of DevOps?
According to Luca, Platform Engineering is really an evolution of DevOps, but unfortunately, in practice, it is often just DevOps rebranded.
Just like Sys Admins were rebranded to DevOps engineers 15 years ago, a lot of DevOps engineers now get rebranded as Platform Engineers. But just rebranding is not enough.
The ‘You built it, you run it” philosophy, he says, is good in theory or in teams of 10-20 people, but it doesn’t scale. In organizations with hundreds or thousands of developers with complex infrastructure, there have to be silos of Devs and Ops. People usually don’t like to hear that silos are good, but it works if you build efficient communication layers between them.
One of the points of having a platform layer is to create standardized golden paths that are designed and automatically enforced across different development teams. But standardization does not mean a lack of innovation.
Standardization makes the entire system move faster without breaking things. Most engineering organizations, especially enterprise ones, aim to do that. The platform team is the one building the path but also the option to go off the path. The platform should not only be the enforcing mechanism for best practices but also a discovery mechanism.
Does every company need an IDP? Can there be a platform strategy without an IDP?
Luca says there can’t because, without an official platform initiative, the platform is going to build itself.
At around 50-100 developers you see some sort of platform team form because the problems are not going to magically solve themselves. There can only be either a formal platform initiative or a bottom-up initiative that just forms, so organizations end up having a platform either way.
How do developers get the value out of IDPs?
Internal Developer Platforms tend to be dashboards that mostly serve infrastructure teams to monitor the performance of infrastructure or for engineering leadership to keep track of developer productivity metrics, which is less relevant for day-to-day developer’s workflow.
That’s one of the biggest misconceptions about Internal Developer Platforms, and I’ve spent countless hours of my life explaining the difference between internal developer platforms and portals.
The Internal Developer Portal is just a UI on top of infrastructure set up for the platform team to see what’s going on. It is often wrongly called platform engineering.
Internal Developer Platforms are built with a product mindset, with a focus on what provides real value to their internal customers, the app developers, based on the feedback they give them. Like any other application, they are not just a frontend but also have a backend, which addresses the real pain of developers, issues like streamlining application configuration or infrastructure orchestration.
In enterprise organizations I speak to, a developer waits for weeks to get an environment or a database created. So, they’re stuck waiting and overwhelmed, and afraid of screwing things up. Sometimes, senior developers jump in and help more junior developers set something up, and that’s how so-called shadow operations form. That’s what platform engineering addresses with developer self-service.
Why do Platform Engineering initiatives fail at some companies?
They fail when Platform Engineering is done as just rebranded DevOps.
The solution is not to look at the platform as a ‘one-and-done’ six-month infrastructure project but adopt a product management approach, see the developers as customers, and apply all of the product management best practices to it, from user research and UX to product marketing.
Another piece of advice Luca shares is to look at platform engineering as a cultural challenge and not a technical challenge.
I have yet to see a platform engineering project fail because of the tech stack versus because of not getting developer adoption or stakeholder buy-in.
https://platformengineering.org/blog/ai-and-platform-engineering
Just like Sys Admins were rebranded to DevOps engineers 15 years ago, a lot of DevOps engineers now get rebranded as Platform Engineers. But just rebranding is not enough.
.svg)
-1.svg)
00:00 Introduction to Platform Engineering
01:27 Defining Platform Engineering
03:03 Inner Loop vs Outer Loop in Development
08:15 The Evolution of DevOps to Platform Engineering
12:45 Standardization vs Innovation in Engineering
16:28 The Necessity of Internal Developer Platforms (IDPs)
20:44 The Role of IDPs in Developer Productivity
22:08 Understanding Internal Developer Platforms vs. Portals
28:50 The Developer Experience and Value of IDPs
32:57 Challenges in Platform Engineering Adoption
39:55 The Future of AI in Platform Engineering
