In today’s IT workforce, the lines between DevOps engineers and Platform engineers often blur. Having experienced both roles myself, I’ve worked at organizations where Platform engineers are referred to as DevOps engineers and vice versa. So, what’s the difference?
Defining the Roles
DevOps Engineering
Core Focus:
Facilitating collaboration between development and operations teams.
Streamlining CI/CD pipelines.
Automating and optimizing development and deployment processes.
Key Skills:
Proficiency in CI/CD tools (e.g., Jenkins, GitLab CI).
Strong scripting and automation skills (e.g., Bash, Python, Ansible).
Knowledge of monitoring and logging tools (e.g., Prometheus, Grafana, Splunk).
Experience with cloud platforms (e.g., AWS, Azure, GCP).
Mindset:
Agile thinking and the ability to adapt quickly.
A focus on continuous improvement and integration.
Collaboration across teams to ensure smooth and efficient operations.
Platform Engineering
Core Focus:
Building and maintaining the underlying infrastructure and platforms that support software development and deployment.
Providing a stable, scalable, and secure environment for application deployment.
Ensuring the platform’s reliability, scalability, and performance.
Key Skills:
In-depth knowledge of infrastructure as code (e.g., Terraform, CloudFormation).
Expertise in container orchestration (e.g., Kubernetes, Docker).
Strong understanding of cloud-native architectures.
Experience with monitoring, scaling, and managing large-scale systems.
Mindset:
Focus on long-term stability and scalability of the platform.
Emphasis on creating reusable infrastructure components.
Understanding the importance of security and compliance in platform design.
Comparing the key differences
DevOps Engineer | Platform Engineer | |
Scope of Work | Work more closely with developers to ensure efficient delivery pipelines | Focus on the infrastructure and tools that support these pipelines |
Goals | Faster, more reliable deployments | building a stable and scalable environment that can handle deployments |
Both roles are crucial for the success of a development organization, often working together to bridge the gap between development and operations, with Platform engineers providing the foundation and DevOps engineers optimizing the processes on top of that foundation.
Examples
Throughout my career, I’ve held both roles and witnessed both effective and ineffective use of them. Every organization has unique needs and varying budgets, which can sometimes lead to combining these roles due to financial constraints.
The Good
At one large company, I was part of a “cloud” organization responsible for defining, building, maintaining, and securing all cloud-related services. Any application team wanting to deploy to a major cloud provider had to go through this organization.
This organization consisted of multiple teams, including platform teams that built services like Kafka as a Service and pre-built essential services into each subscription or account, such as logging. There were also DevOps teams that directly collaborated with application teams to use these services and onboard to the cloud. Their activities included creating architecture diagrams for cloud-based projects, conducting security checkups to ensure secure application development, and assisting in building deployment pipelines for the cloud.
This structure worked well for the company. While I’m not advocating that every organization should adopt this exact model—because no approach is ever “perfect”—in my experience, this was one of the better layouts for clearly defining the roles of Platform versus DevOps engineers.
The Bad
When I say “bad,” I don’t mean to imply that this should never be done. I’m simply sharing my experiences with approaches that didn’t work well on the teams I was part of. I’ve been at companies that combined Platform and DevOps engineering roles.
For instance, I was on a team responsible for building and maintaining a Kubernetes platform. This team handled everything from building and upgrading the platform to monitoring and maintaining it. However, they were also tasked with assisting application teams using the platform. In theory, this can work, and I’ve seen it function adequately in some cases. But more often than not, the engineering team becomes overwhelmed with tasks. They face constant deadlines for features or upgrades while simultaneously trying to support application teams that have their own deadlines to meet for deploying to the platform. This creates a conflict—should the platform team prioritize platform stability or application deployment? While application teams drive revenue, without a stable platform, those applications are at risk.
Additionally, if the platform team is also responsible for pipelines, and the organization doesn’t standardize on a single pipeline tool, the engineers need to be experts in a variety of tools; Jenkins, GitHub Actions, GitLab, and whatever else the application teams prefer to use.
Not every engineer is inclined or equipped to engage with developers to help them use the platform. I’ve worked with many engineers who believe, “If you can’t figure it out, that’s your problem.” While I understand this sentiment, especially when faced with competing priorities and the desire to build a stable platform, application teams need to focus on developing their applications, not on building pipelines or managing Kubernetes. They are developers first and need a straightforward way to deploy their applications successfully.
In other companies, I’ve seen application teams take a completely hands-off approach. They develop their application, then essentially throw it over the wall, saying, “Here it is, now deploy it,” sometimes with a “please” added. This rarely ends well because the “deployment engineer” doesn’t know or understand the application’s requirements. For instance, they might not realize the application needs Python 2.7 instead of 3.10.
Conclusion
If your company can afford it, in my opinion, it’s best to build out separate Platform and DevOps engineering teams. Combining these roles often leads to the issues I outlined in the “The Bad” section above.