Skip to content

PATTERN Cited by 1 source

Mono-repo for serverless fleet

Intent

Consolidate many microservices into a single repository to enforce uniform tooling, security scanning, and CI/CD guarantees across a large serverless fleet where governance cost dominates development velocity.

Problem

At 20+ microservices deployed across thousands of accounts (1M+ Lambda functions), each with its own repo, library versions, CI pipeline, and security scanning configuration, governance overhead compounds: runtime upgrades require coordinated changes across all repos, security patches miss edge cases, and inconsistent tooling creates drift.

Solution

Consolidate all microservices into a single mono-repo with a unified CI/CD pipeline: - Every change passes the same build/test/security chain. - Runtime and library upgrades are applied in one coordinated commit. - Security scanning tooling runs uniformly — no service can opt out or lag behind. - Configuration is a single source of truth for all services.

Trade-offs

Pro Con
Guaranteed consistency across fleet Larger repo, longer CI for unrelated changes
Single-point runtime upgrades Blast radius of a bad merge affects all services
Uniform security scanning Requires sophisticated CI to avoid rebuilding everything
Simpler dependency management Team ownership boundaries less clear

When to apply

  • When governance cost (keeping N services in sync) exceeds the development-velocity cost of mono-repo tooling.
  • When the fleet is homogeneous (same runtime, same patterns, same deployment mechanism).
  • When security/compliance requirements demand provable uniformity.

Seen in

Last updated · 562 distilled / 1,660 read