This article is based on a piece originally published on Forbes.com (2017) by a technology leader at AppLovin. The core principles remain highly relevant to DevOps practitioners today.
If you work in tech, you almost certainly have an opinion on DevOps. Critics argue it creates organisational friction and blurs accountability. Advocates — and there are many — say it is indispensable for shipping software reliably at scale. The truth is that both camps can be right, depending on how the practice is implemented. DevOps done badly is expensive noise. DevOps done well is a sustainable competitive advantage. The difference usually comes down to a handful of deliberate choices about what your DevOps team is actually responsible for.
The following three principles are drawn from operational experience at a high-growth technology company. They are intended for engineering leaders, platform engineers, and anyone responsible for shaping a DevOps function.
1. Task DevOps With Differentiating Your Technology Foundation
Commodity cloud services — AWS, Google Cloud Platform, Microsoft Azure — are genuinely excellent. They are also available to every one of your competitors on identical terms. Selecting a major cloud provider gets you to parity, not ahead. Real competitive advantage comes from what you build on top of, or alongside, the commodity layer.
A well-directed DevOps team can exploit lower-level differentiation that off-the-shelf cloud configurations do not expose. Examples include:
- Hardware-level tuning: Selecting workload-specific processors, or leveraging NVMe or high-throughput flash storage for latency-sensitive applications, can yield significant performance gains compared with default cloud instance types. The exact multiple depends heavily on the workload, but the principle — that specialised hardware outperforms generalised configurations for specific tasks — is well established.
- Hybrid deployment strategies: Intelligently mixing bare-metal co-location, private data centres, and public cloud regions allows you to optimise cost and latency simultaneously. This kind of blended architecture requires deliberate engineering; it does not emerge from simply clicking through a cloud console.
- Custom tooling for your specific domain: Generic infrastructure-as-code templates work for generic problems. If your product has unusual traffic patterns, data access patterns, or compliance requirements, bespoke automation built by your DevOps team will outperform off-the-shelf solutions.
The practical implication: when you scope your DevOps team’s roadmap, include explicit work items around infrastructure differentiation. If every sprint is pure maintenance, you are running fast to stand still.
2. Build Tools That Let Engineering Scale Without Adding Headcount
One of the clearest measures of a healthy DevOps function is whether it reduces the per-engineer operational burden over time. If onboarding a new engineer requires a week of manual environment setup, or if deploying to production requires a specialist in the room, your DevOps team has not yet solved the scaling problem.
The mechanism that makes scaling possible is systematic automation. Every infrastructure decision should be deliberate, documented, and encoded as repeatable automation rather than tribal knowledge. Concretely, this means:
- Automated server provisioning: New capacity should be spun up via code, not manual clicks. Tools such as Terraform, Ansible, or Pulumi make this reproducible across environments.
- Automated deployment pipelines: Code should flow from development through staging to production via a CI/CD pipeline (Jenkins, GitHub Actions, GitLab CI, and similar tools are common choices) with automated tests acting as gatekeepers at each stage.
- Automated anomaly detection and alerting: Observability stacks — combining metrics (Prometheus, Grafana), logs (the ELK stack or similar), and traces (Jaeger, OpenTelemetry) — should surface problems before users report them.
- Environment consistency: Configuration management tools (Chef, Puppet, Ansible) and container orchestration (Kubernetes) ensure that the environment a developer tests against matches what runs in production, eliminating entire categories of “works on my machine” bugs.
The test of success: can a developer who joined last month ship a feature to production without filing a ticket with the DevOps team? If the answer is yes, the platform is working. If the answer is no, the DevOps team is a bottleneck rather than an enabler.
3. Never Let DevOps Become an IT Help Desk
This is the most common failure mode for DevOps teams, and it is worth stating plainly: the moment your DevOps engineers are spending the majority of their time on laptop configuration, VPN access requests, or user onboarding, the team has become an IT support function. That is not a criticism of IT support — it is a legitimate and important discipline — but it is a completely different job with a completely different value model.
DevOps exists to drive infrastructure innovation and engineering velocity. IT support exists to keep individual users productive. Conflating the two harms both outcomes: users get slower support from engineers who resent the interruption, and infrastructure work stalls because the engineers are distracted.
How to detect the IT trap: Review your DevOps team’s ticket queue or task tracker. Ask these questions:
- What percentage of tickets come from individual users requesting help with their devices or access permissions?
- What percentage represent architectural improvements, performance work, or tooling that benefits all engineers?
- Is the ratio shifting over time — more user requests, fewer infrastructure projects?
A practical heuristic: if more than roughly 10% of DevOps capacity is absorbed by individual user requests, you have a structural problem worth addressing. The fix usually involves one of three approaches: hiring dedicated IT support staff, implementing self-service tooling (identity management platforms, automated access provisioning), or explicitly re-scoping the DevOps team’s mandate in writing so that boundaries are clear.
Putting It Together
None of these principles require a large team or a large budget. They require clarity of purpose. A DevOps team that knows it is responsible for differentiating the infrastructure, enabling engineers to scale independently, and staying out of the IT support business will naturally make better decisions about how to spend its time.
Conversely, a DevOps team without that clarity will drift toward whatever is loudest and most urgent — which is almost always user-facing problems rather than strategic infrastructure work. The loudest problems are rarely the most important ones.
If you are building or restructuring a DevOps function, start by writing down what the team is not responsible for. That boundary-setting exercise often reveals misalignments faster than any amount of process documentation. Once the scope is clear, the three principles above give you a practical framework for evaluating whether the team is delivering real business value — or just keeping the servers on.