"DevOps" means different things to different people. To some it's a job title. To others it's a culture, a set of tools, or a team that sits between development and operations. That ambiguity can make it hard to have a clear conversation about what you're actually building, buying, or hiring for. So for the purposes of this post — and as a stake in the ground we use when we talk about platform and delivery — we're defining DevOps as follows.
What We Mean by DevOps Here
We take DevOps to mean the productization or platformization of every component and system responsible for delivering and running applications, plus the standardization and automation of those systems, and the specialization and/or generalization of the roles that own them. Concretely, that includes:
- Application development capability — the environments, tooling, and workflows that let people write, run, and test application code.
- Application build capability — how source code is turned into build artifacts (e.g. container images) in a repeatable, auditable way.
- Build artifact repository capability — where those artifacts are stored, versioned, and promoted (e.g. container registries).
- Deployment process capabilities — how artifacts are deployed into environments, who triggers it, and how it's tracked.
- Runtime, environment-specific configuration — managing desired state (what should be running where, with which config) and actualization of that state (making the real system match that desired state), as well as keeping the runtime environment and the code/config deployed to it stable, performant, secure, scalable, and so on.
- Code promotion, release, and change process — how application code and configuration move from one stage to the next (e.g. DEV → QA → STAGING → PROD) and how changes are approved and recorded.
- Standardization of configuration, process, and procedure — consistent patterns for config, runbooks, and automation so that the above isn't ad hoc.
- Automation when practical — we seek to automate where the benefit is worth the cost and investment, not "automate everything" for its own sake; reducing manual steps and human error while keeping control and auditability.
And alongside all of that:
- The specialization and/or generalization of roles responsible for these capabilities — whether that's dedicated platform or DevOps engineers, or developers and operators sharing responsibility, or a mix.
The same philosophy and approach can and ought to be applied further up and down the stack. That includes standardizing and refining build and deployment archetypes (so teams don't reinvent the same patterns repeatedly), and productizing and standardizing — and automating where practical — lifecycle management of infrastructure: provisioning, change, and retirement of the underlying platforms and resources that applications run on.
So in this framing, DevOps isn't just "dev and ops working together" or "CI/CD." It's treating the entire chain — from writing code to running it in production, including config, release, and desired state — as something you productize and platformize: with clear boundaries, automation where it pays off, standards, and roles. Ultimately, DevOps is about delivering value and continuously improving people, processes, and products so that value delivery and innovation keep increasing. That's the definition we're using when we talk about DevOps at essesseff, and we offer this as a concrete starting point so you can compare it to your own and refine the conversation.
Further Reading and Contextual Layers
We encourage deeper reading on a few topics that sit underneath this definition. First, the use of configuration management in application, platform, and infrastructure contexts: establishing and maintaining consistency of a system's performance, functional, and physical attributes with its requirements and operational information over its life (see Configuration management and Configuration item). In that light, it's useful to think about an application as a configuration item and its relationship to the build and deployment archetype(s) it is based on — the standard patterns (e.g. container image, Helm chart, GitOps promotion) that define how that app is built, deployed, and operated. Treating the app and its archetype as distinct but related configuration items helps keep changes to "what we run" separate from changes to "how we run it," and supports reuse and consistency across many applications.
Second, we suggest using at least three contextual layers to divide and loosely couple products, platforms, and the roles mapped to them. Layering helps avoid a single monolithic "DevOps" blob where responsibilities and escalation paths are unclear. Familiar patterns from support and project management are relevant here: tiered or multi-level structures (e.g. multi-level technical support) and explicit responsibility assignment (e.g. RACI) so that who is responsible, accountable, consulted, or informed is clear per context. At a minimum, distinguishing application, platform, and infrastructure (or similar) contexts — each with their own configuration items, lifecycle, and roles — gives you clearer boundaries and better separation of concerns.
essesseff provides an opinionated framework and platform for the application and platform contexts specifically, in relation to Kubernetes-deployed archetypes. We focus on standardizing how apps are built (e.g. container images from source), how they are promoted through DEV → QA → STAGING → PROD, and how platform-level configuration (e.g. image tags, Helm values) is managed and driven from Git — without owning your cluster or your infrastructure context. That way you can apply configuration management and clear contextual layers across the stack while using essesseff to productize and streamline the app and platform layers for K8s-based delivery.
Previous: Architectural Design Principles We Value