Roles and Responsibilities Across the Service Lifecycle

Recommended resources

The freely available resources this lesson will direct you to.

Welcome to the first lesson. This course develops the practical foundation shared by Site Reliability Engineering and DevSecOps: operating cloud services that are dependable, secure, observable, and changeable without unnecessary risk.

The job titles in this area overlap considerably. A company may call someone a “DevOps engineer” while expecting platform work, security automation, and on-call support. Rather than treating titles as rigid categories, this lesson gives you a clearer way to distinguish the problems each discipline is primarily responsible for solving across a service’s life: from idea and design through launch, operation, and retirement.

By the end, you should be able to look at a task such as “add deployment approvals,” “define an availability target,” or “make a safe Kubernetes deployment path” and identify the likely lead role, collaborators, and intended outcome.

Four disciplines, four primary concerns

Consider a team building an online order service. It receives customer requests, stores orders, charges payments, and sends confirmation messages. All four disciplines may touch this service, but they approach it from different directions.

Discipline	Primary question	Typical durable outputs	Core responsibility
Application development	Does the service correctly deliver useful product behavior?	Application code, tests, APIs, database schema, product features	Business logic and correctness of the application
Platform engineering	Can teams build, deploy, and operate services through a safe, repeatable path?	Internal developer platform, Kubernetes templates, CI/CD capabilities, observability integrations	Shared infrastructure and developer self-service
SRE	Does the service meet its reliability goals under real production conditions?	SLOs, dashboards, alerts, capacity plans, operational automation, incident practices	Reliable production operation and reliability engineering
DevSecOps	Is security built into delivery and operation rather than checked at the end?	Threat-model practices, security checks in CI/CD, policy controls, vulnerability processes, audit evidence	Continuous, automated security assurance shared across teams

Two cautions are essential:

DevSecOps is primarily a practice and operating model, not necessarily a separate team. An organization may employ DevSecOps engineers, but the central idea is that security becomes part of how developers, platform engineers, operators, and security specialists all work.
Ownership is not isolation. Application developers still own their application even when an SRE team supports it. An SRE may own a service’s production reliability, but must work with developers to fix product-code defects. A platform team may offer a deployment system, but it should not silently become responsible for every application deployed through it.

A useful shorthand is:

Application development owns what the service does.
Platform engineering owns the paved road used to build and run services.
SRE owns how reliably important services behave in production.
DevSecOps ensures security controls and evidence are integrated throughout that work.

This is a helpful first model, but it becomes meaningful only when we apply it over time.

DevOps vs SRE vs Platform Engineering | Clear Big Misconceptions

Watch “DevOps vs SRE vs Platform Engineering | Clear Big Misconceptions” from ByteByteGo for a concise orientation to the overlap among DevOps, SRE, and platform engineering. Treat it as a vocabulary-setting overview; the lifecycle map below adds the operational detail.

Start with DevOps framing for the “you build it, you run it” idea. Watch title overlap to keep job-title ambiguity in perspective. Then watch the SRE role and platform engineering; focus on SRE’s use of software engineering for operational problems and platform engineering’s enabling role. Finish with the conclusion, which explains why these approaches coexist rather than replace one another.

DevSecOps: security as a continuous property

In a traditional organization, a development team might build a feature, an operations team might deploy it, and a security team might inspect it late in the process. That sequence creates a predictable problem: security findings arrive when architecture choices, code, dependencies, and release deadlines are already difficult to change.

DevSecOps changes both the timing and the distribution of responsibility. Security becomes part of design, coding, testing, delivery, deployment, and runtime operation.

For the order-service example, that could include:

During design, identifying payment data and customer information as important assets.
During coding, avoiding unsafe input handling and ensuring secrets are never hard-coded.
During CI, scanning dependencies and application code for known vulnerabilities.
During deployment, checking container configurations and enforcing approved environments.
During runtime, monitoring for suspicious access, exposed credentials, or vulnerable workloads.
After an incident, preserving evidence, fixing the underlying weakness, and preventing recurrence.

The goal is not to make every application developer a full-time security specialist. It is to make secure choices practical, visible, and repeatable, while security specialists provide standards, expertise, and escalation paths.

What is DevSecOps? - Developer Security Operations ...

Read AWS’s overview to establish the central DevSecOps idea: security is integrated into software delivery and becomes a shared responsibility rather than a final gate.

In “What is DevSecOps?” and the subsection “What does DevSecOps stand for?”, read the core definition. Note the distinct meanings of development, security, and operations. Next, in “Why is DevSecOps important?” under “DevSecOps in the SDLC,” read the timing shift. Then read the “DevSecOps” subsection in “DevSecOps compared to DevOps,” especially the shared-responsibility comparison. Finally, skim “What is the DevSecOps culture?” for the collaboration and automation implications.

The secure-development-lifecycle diagram below is a useful visual reminder that security is not one scan inserted before release. It includes design work, code review, automated checks, artifact controls, infrastructure checks, runtime monitoring, and feedback into future changes.

A Secure Development Lifecycle diagram showing security activities across design, coding, continuous integration and testing, delivery and deployment, and runtime monitoring. Secrets management, feedback, telemetry, and governance span the entire lifecycle rather than belonging to a single stage.

Not every team needs every tool shown in the diagram on day one. The principle is more important than the tool list: use proportionate controls, automate what can be automated, and preserve human review for decisions that require context.

SRE: production reliability as an engineering discipline

SRE applies software engineering to operational work. Rather than responding to every production problem manually, an SRE seeks to make the service observable, measurable, scalable, and increasingly automated.

For a production service, SRE concerns commonly include:

Architecture and dependencies: What external systems can make this service fail? Are there single points of failure?
Instrumentation: Can we tell whether users are succeeding, how long requests take, and where failures occur?
Service levels: What reliability target is appropriate, and how much unreliability is acceptable within a stated period?
Capacity and performance: Will the service remain responsive as traffic grows?
Change management: Can releases and infrastructure changes be made safely and reversed when needed?
Incident response: Who responds when user impact occurs, and what operational knowledge is documented?
Continuous improvement: What must change after incidents, near misses, or new demand reveal a weakness?

SRE does not mean that SRE engineers own every bug or every feature decision. If a newly released checkout rule charges the wrong tax rate, the application team needs to diagnose and correct the business logic. If the checkout API exceeds its latency objective because database connections are exhausted at peak load, SRE and developers may work together on capacity, limits, caching, query efficiency, and safe degradation.

The curve below captures an important idea: SRE value is often highest when reliability thinking begins early, before design choices become expensive to reverse. That does not mean an SRE must be embedded full-time in every project. The intensity of involvement should reflect service criticality, scale, risk, and organizational capacity.

A service-lifecycle graph showing SRE involvement beginning during architecture and design, continuing through development, limited availability, and general availability, then declining during deprecation toward end of life. The curve emphasizes early reliability input and sustained production engagement rather than a one-time handoff.

Production Readiness Review: Engagement Insight

Read selected parts of Google SRE’s engagement model to see how production responsibility, early reliability involvement, and shared platforms relate to one another.

In “The SRE Engagement Model,” read the production concerns. This is the most direct source for the operational scope of SRE. Then move to “Evolving the Simple PRR Model: Early Engagement.” Read the early-engagement model, followed by the “Design phase,” “Build and implementation,” and “Launch” subsections. Focus on why instrumentation, controls, and launch practices are cheaper to introduce before production. Finally, in “Toward a Structural Solution: Frameworks,” read the shift toward frameworks. This explains an important overlap: a scalable SRE organization often helps create platform capabilities that let developers build reliable services by default.

Platform engineering: making the reliable path the easy path

Platform engineering creates and operates an internal product for engineers: a platform that reduces repeated infrastructure work and provides a consistent way to build, deploy, observe, and secure services.

Suppose every application team has to independently decide:

how to create cloud accounts and IAM roles;
how to package and deploy containers;
how to configure logs, metrics, and tracing;
how to store secrets;
how to add security scans;
how to request databases, queues, or certificates;
how to roll back a failed deployment.

The result is usually inconsistent configurations, duplicated effort, risky improvisation, and a large support burden for SRE and security teams.

A platform team can instead provide “golden paths”: documented, supported defaults such as a standard CI/CD template, a secure container base image, a Terraform module for a database, an approved Kubernetes deployment pattern, and built-in telemetry. Developers retain choice where it matters, but routine choices become safer and faster.

The distinction from SRE is easiest to see in the unit of ownership:

An SRE team often focuses on the reliability of particular critical services, a fleet, or a production environment.
A platform engineering team focuses on reusable capabilities consumed by many engineering teams.
In smaller organizations, the same people may perform both functions. In larger organizations, they often collaborate closely but have different customers and success measures.

A platform’s customers are internal developers. Its success is measured not only by uptime, but also by adoption, developer experience, standardization, speed of safe delivery, and reduction of cognitive load.

Who leads at each stage of the lifecycle?

The following lifecycle view is a practical guide, not a rigid organizational chart. “Leads” means the group most responsible for driving the work; it does not mean other groups are absent.

1. Idea and architecture

Application developers and product stakeholders define user needs, major workflows, and application behavior. They identify what the service is intended to do.

DevSecOps practices begin here with threat modeling: identifying valuable assets, likely attackers, trust boundaries, and appropriate protections. Platform engineers advise on approved architectural patterns and available capabilities. For a service expected to be high-traffic or business-critical, SRE contributes reliability requirements, dependency analysis, capacity assumptions, and observability expectations.

Example: A team plans to process customer payments. Application development owns the payment workflow; security specialists and DevSecOps practices help identify card-related data and access risks; platform provides approved secret storage and workload identity; SRE reviews dependency and availability expectations for critical payment paths.

2. Build and test

Application developers lead implementation, code review, unit and integration tests, API behavior, and correct handling of data. They are responsible for fixing defects in their code.

DevSecOps integrates checks such as static analysis, dependency scanning, secret detection, and policy checks into the normal workflow. Platform engineering provides reusable build systems, standardized templates, artifact repositories, and safe default configurations. SRE focuses on production-relevant qualities such as meaningful metrics, structured logs, safe resource limits, and failure behavior.

3. Delivery and release

Platform engineering commonly owns the deployment capabilities: CI/CD foundations, infrastructure modules, cluster services, artifact storage, environment provisioning, and access patterns.

Application teams decide what version of their service is ready to promote and validate that its behavior meets functional requirements. DevSecOps ensures that promotion requirements include security controls and traceable evidence. SRE helps define and validate safe rollout practices for important services, such as gradual rollout, monitoring during release, rollback readiness, and appropriate service-level objectives.

4. Production operation

SRE is most visibly involved here. It measures user-facing reliability, builds alerting around meaningful symptoms, prepares for incidents, plans capacity, and automates repetitive operational work.

Application developers remain necessary: they understand product behavior and own fixes to application defects. Platform engineering keeps the shared platform reliable, secure, and usable. DevSecOps continues through runtime security monitoring, vulnerability management, access review, incident evidence, and remediation processes.

A production incident often crosses boundaries. For example, a spike in failed orders might require:

SRE to assess user impact and coordinate mitigation;
developers to identify a defective change or database query;
platform engineers to investigate a shared cluster, network, or deployment-system fault;
security personnel and DevSecOps controls to investigate if there are indicators of compromise or unauthorized changes.

5. Evolution and retirement

Services evolve: dependencies change, data grows, users demand features, and security threats shift. Application teams make functional changes. Platform teams update supported foundations and help teams migrate from obsolete capabilities. SRE uses incidents and operational data to drive reliability improvements. DevSecOps updates controls as risks, regulations, dependencies, and attack techniques change.

At retirement, the work is still not merely “turn it off.” Teams must safely migrate users and data, remove credentials and access paths, retain required audit evidence, and decommission infrastructure without leaving exposed or billable resources behind.

A decision rule for ambiguous tasks

When a task seems to fit multiple roles, ask four questions:

Is it primarily about user-facing behavior or domain correctness?
The application team should lead.
Is it a reusable capability used by many teams?
Platform engineering should usually lead.
Is it about meeting a measurable reliability outcome in production?
SRE should usually lead or be deeply involved.
Is it about reducing, detecting, or responding to security risk throughout delivery and operation?
DevSecOps practices should be embedded, with security specialists providing expertise and governance where needed.

For example, “add a dependency vulnerability scan” is mainly a DevSecOps concern, but the platform team may provide the CI integration, developers must fix vulnerable dependencies, and security specialists may define the severity threshold. There is no contradiction in this shared work. Clear ownership means naming a lead and an expected outcome, not pretending that collaboration is unnecessary.

Key takeaways

The four disciplines work on the same service but optimize different aspects of it:

Application development delivers correct product behavior.
Platform engineering supplies reusable, self-service foundations for engineering teams.
SRE engineers and operates for measurable reliability in production.
DevSecOps integrates security practices and controls continuously across the lifecycle.

The boundaries overlap, especially between SRE and platform engineering, and DevSecOps spans every role. The reliable organizational pattern is not a perfect handoff between silos; it is explicit ownership, shared operational knowledge, and automation that makes secure and reliable practices routine.

Next, we will follow a web request through cloud networking and application components. That request path will make these responsibilities more concrete by showing where reliability and security boundaries actually appear in a running service.