Whether you look at the growing adoption of new industry standards like reference architectures and the MVP framework, or even just at the quality of talks and conversations at events like KubeCon and PlatformCon, it’s obvious that the platform engineering space has been maturing quickly.
At the same time though (and like most trends) we still see a lot of simplistic rebranding. Teams that used to be SysAdmins or Ops and had rebranded to DevOps because it was cooler and made more money, are now doing the same thing and rebranding to platform teams for the same (wrong) reasons. This further confuses the industry as to what are the actual differences between DevOps, SRE and Platform Engineering.
This also doesn’t help engineering organizations that are trying to figure out the right operating model combining platform engineering, SRE and DevOps that can work for them. What is the right operating model to win?
DevOps was never meant to be a job title of course. It was a cultural shift meant to tear down silos and walls between devs and ops teams. Often in combination with a “shift left” movement that meant declining developer productivity and lower ops efficiency.
Platform engineering was born out of the need to address such inefficiencies at scale. It aims at delivering a platform layer in between devs and ops, an Internal Developer Platform (IDP), built following a “platform as a product” approach.
In contrast, many DevOps teams support on a team or individual level with certain tooling, but they do not really solve org-wide problems.
Concrete team responsibilities
But beyond such general statements, we should get this more concrete.
To have a high-performing engineering organization, you need clear responsibilities with clear ownership, where every team knows exactly what they own and what they need to take care of.
- Platform Team:
- Configures and manages the platform’s golden paths, including baseline infrastructure and application configurations.
- Creates and maintains resource definitions and packs, ensuring consistency across environments and enabling ease of use for developers.
- Responsible for platform-specific tooling (e.g., Platform Orchestrator, Workload Spec, Portal) and the overall developer experience, ensuring developers can easily interact with and leverage the platform.
- Manages delivery and deployment tooling, including CI/CD pipelines and the deployment processes for platform services.
- DevOps/Cloud Operations/SRE Team :
- Provides input on infrastructure configuration standards and ensures that cloud infrastructure is set up securely, efficiently, and in line with the platform team’s needs.
- Responsible for cloud infrastructure management, including compute, storage, and networking, ensuring high availability, redundancy, and disaster recovery.
- Manages core security controls at the cloud level, including IAM, physical security, and compliance at the infrastructure layer.
- Application Developers:
- Build, test, and deploy applications using the tools, golden paths, and pre-configured workflows provided by the platform team, while adhering to platform best practices.
- When necessary, leave the golden path to address specific application performance needs or other critical requirements, creating custom configurations as needed.
- Share any new configurations developed with the Platform Engineering Team, who can evaluate and decide whether to make these configurations available as part of future golden paths or standard workflows.
- Provide feedback on platform functionality and usability, working collaboratively to drive platform enhancements.
A more detailed view could look like this:
And SRE?
You might ask now, where does SRE fit into this. According to Google, who came up with SRE initially, SRE teams are responsible for system availability, latency, performance, monitoring, emergency response, and capacity planning (computing resources). So you see, there is a high overlap with the ops team as we defined it above. In the end, the main responsibility of SRE remains the reliability of production environments. They are important stakeholders but not part of the platform team, and their responsibilities overlap with those of modern cloud ops or DevOps teams.
Summary
It’s important to understand that your platform team doesn’t replace your existing SRE or Infra and Ops teams. It complements them. You still need people running your infrastructure, optimizing and maintaining it. But at enterprise scale, you also need someone repackaging that in a self-serviceable layer to drive automation and standardization by design, across all your teams and workflows. Ultimately impacting your time to market. As for DevOps teams, engineering organizations are finally realizing having one didn’t really make sense in the first place. Infrastructure, SRE and platform teams cover all your bases and it’s the right operating model and separations of concerns that sets top performers apart from the rest of the industry.