Developers Should Deploy Their Own Code

Aug 10, 2022

This is the platonic ideal. We're not there yet, but the all signs point to this rather than specialization.

Applications and their infrastructure (functions, queues, permissions, runtime) have always been closely intertwined. Fewer handoffs mean quicker deployments and less context loss.

So – Why can't developers deploy their own code (yet)?

  1. Provisioned infrastructure economy1

Competing product teams must be allocated resources at companies with provisioned infrastructure. Finance departments must be able to track resource spend per project and per department.

Why it doesn't matter anymore: usage-based cloud infrastructure includes mechanisms to track spending (e.g., AWS resource tags, separate accounts, budget limits), and with the right tools, finance can get real-time breakdowns.

2. Lack of expertise

Many developers might not know how to deploy their services to production. Frontend engineers who don't know how to write a Dockerfile to backend engineers who don't know Terraform.

Why it doesn't matter anymore: Infrastructure-as-code is increasingly targeting developers rather than IT or DevOps personas. You can see this in the focus on Typescript for infrastructure rather than templating languages or configuration DSLs. The abstractions keep getting better. Cloud infrastructure APIs replace many DevOps functions – provisioning servers, monitoring, and observability.

3. Focus

Developers might be best at debugging their own applications in production but don't want to be on-call. Site reliability engineers might be better at fine-tuning infrastructure. It's often easier to centralize production access to a smaller group of dedicated engineers (rather than the entire development team).

Why it doesn't matter anymore: More small-ops (I won't say zero) deployment options. Things still go wrong but are a class of problems that can be solved more efficiently by developers directly. Different failure modes enabled by new technology (fault-tolerant design) mean that sometimes issues don't need to be resolved immediately – e.g. fallback to CDN, self-healing services, and multiple replicas.

4. Organizational (Authorization/Compliance)

Organizations need to enforce policies regarding who can access what. Who can access the production database? Who can spin up new infrastructure? The easiest solution was an IT/DevOps team that managed the permissions and elevated access on behalf of the developers. This centralized the responsibility.

Why it doesn't matter anymore: Cloud infrastructure also has a robust identity management solution. Users (and machines) can be authorized to specific actions with audit logs. This is far better than any off-the-shelf product or solution an IT department could develop.

5. Reusing workflows

A platform team can build abstractions that are used by multiple product teams. This also standardizes deployments and infrastructure, making it easier for downstream teams to manage.

Why it doesn't matter anymore: Platform development is undifferentiated work, and few (if any) teams can keep up with open source or cloud provider abstractions. Every platform expands until it exposes most of the underlying infrastructure.

1My own story about getting around the IT department.

Subscribe for daily posts on startups & engineering.