3 posts tagged with "platform engineering"

Modern software organisations increasingly rely on three disciplines that overlap but are distinct: DevOps, Site Reliability Engineering (SRE), and Platform Engineering. While all three aim to increase efficiency, automation, and reliability in delivering software, they differ in focus, scope, responsibilities, metrics, and organisational expectations.

This guide clarifies the differences across several practical dimensions to help you navigate these roles effectively.

Core Definitions: What Each Discipline Means​

DevOps​

• A cultural movement and set of practices whose goal is to break down silos between Development and Operations, enabling faster, higher-quality software delivery through collaboration, automation (CI/CD), shared accountability, and iterative improvement.
• It is fundamentally about culture and process rather than a specific team or organisation structure.

Site Reliability Engineering (SRE)​

• A software engineering discipline that applies software engineering practices to operations problems with the core purpose of ensuring reliability, uptime, scalability, and performance of production systems.
• Originally formalised at Google, SRE uses engineering approaches (automation, monitoring, SLOs/SLIs, error budgets) to run systems reliably at scale.

Platform Engineering​

• An engineering discipline focused on building and maintaining internal platforms, tooling, frameworks, and self-service capabilities that accelerate developer productivity and standardise infrastructure.
• Platform Engineering treats the set of internal tools as a product for developers.

Primary Focus and Objectives​

Introduction: Why Measuring Software Delivery Is Hard​

For decades, the software engineering industry has grappled with a persistent and often frustrating challenge: how do you accurately measure productivity and effectiveness in a domain built on creativity, problem-solving, and constant evolution? Historically, attempts to quantify engineering output have often fallen short, leading to misguided strategies and unmet expectations.

We have seen countless organizations cling to traditional metrics that, while seemingly logical, ultimately fail to paint a complete or accurate picture. Metrics like "lines of code written" are easily gamed and bear little correlation to actual value delivered. "Developer utilization rates" often encourage busyness over impact, fostering a culture where looking busy is prioritized over shipping high-quality software. Even "story points velocity," a staple of agile methodologies, can become an internal-facing measure that, when weaponized, drives teams to inflate estimates or sacrifice quality for perceived speed, rather than focusing on the actual outcomes for users and the business.

The fundamental flaw in these traditional approaches is their focus on activity or output rather than outcomes. Within the complex, adaptive nature of software delivery, simply tracking what engineers do does not tell you if what they are doing is actually effective, valuable, or sustainable. We need a shift in perspective, moving from internal process metrics to external, outcome-oriented delivery metrics that reflect the health and performance of the entire software delivery system.

This is where DORA enters the conversation. The DevOps Research and Assessment (DORA) group has revolutionized how we think about software delivery performance, providing a robust, research-backed framework that has fundamentally reshaped industry discourse. This article will delve into the four core DORA metrics, explaining what they measure, why they matter, and how they work in concert to define modern software delivery success. We will explore their power to foster better conversations, drive meaningful improvements, and align engineering efforts with business objectives.

What this article will not cover are the intricacies of setting up DORA metric collection tools, nor will it prescribe specific technical solutions. Our focus is on the foundational understanding and strategic application of the metrics themselves.

Continuous Integration and Continuous Delivery (CI/CD) systems sit at the center of modern software delivery. They are not merely automation tools; they are strategic delivery platforms that directly influence deployment frequency, lead time for changes, operational stability, and developer productivity.

As organizations scale—adding more teams, services, environments, and compliance requirements—the question inevitably arises: Should we rely on a managed CI/CD service, or should we build and operate our own self-hosted CI/CD platform?

This decision is deceptively simple on the surface and deeply consequential in practice. It affects:

• Engineering velocity and autonomy
• Platform team workload and operating costs
• Security posture and compliance readiness
• Long-term flexibility and vendor dependence

In most organizations, this decision is owned jointly by platform engineering teams, DevOps leaders, and senior technology leadership (CTO / VP Engineering). It is often revisited multiple times as the organization evolves.

Common failure modes include:

• Choosing managed CI/CD too early, leading to hidden scale or customization constraints later
• Choosing self-hosted CI/CD too early, creating unnecessary operational burden
• Treating the decision as a tooling choice rather than a platform and operating-model decision

This article provides a structured decision framework to help engineering leaders make this choice deliberately, contextually, and defensibly.