The platform a microservices estate assumes
A microservices architecture is a bet that the marginal cost of the next service is near zero. If creating a service means a week of pipeline work, secret provisioning and alert configuration done slightly differently each time, the bet is lost and the estate becomes a collection of snowflakes with no shared upgrade path. The platform is not overhead attached to the architecture. It is the thing that makes the architecture affordable.
What does a new service need on day one?
More than most plans account for. A repository from a template, a build that produces a signed and scanned image, a deploy pipeline with a rollback, somewhere to run, a way to receive configuration and secrets without either being in the image, an identity so other services can authenticate it, ingress with a certificate, a database that somebody provisioned and backs up, instrumentation wired to the same backends as everything else, health endpoints the orchestrator understands, an alert that pages a specific rota, and a written record of who owns it.
That is roughly fifteen decisions. Made once, centrally, they are a template. Made by each team as they go, they become fifteen variations per service, and the variations are invisible until the day something has to change across all of them.
This is why the question 'how long does it take to get a new service into production' is the single most diagnostic question about a microservices estate. If the answer is measured in days, the architecture is working. If it is weeks, teams will start adding features to existing services to avoid the process, and the boundaries will drift.
What is a platform team actually for?
Making the correct way to do something also the easiest way. A platform team's output is a paved road: a service template, a standard pipeline, shared libraries for instrumentation and authentication, and defaults that are already right. Teams that follow it get the whole checklist for free; teams that need something different can leave the road, and they own the consequences.
The distinction that matters is between a paved road and a gate. A platform team that reviews and approves every deployment reintroduces the coordination that the split was meant to remove, and becomes the bottleneck the architecture was avoiding. The measure of the team is whether other teams ship faster because of it, not whether standards were enforced.
The other output is upgrades. When a vulnerability appears in a base image or a language runtime, someone needs to be able to move the whole estate, which is only possible if the estate shares a base image and a pipeline in the first place. That capability is built long before it is needed and cannot be assembled during an incident.
Which capabilities are actually required?
Fewer than a platform vendor will suggest and more than a team of six can improvise. This is the honest minimum, with the consequence of skipping each.
| Capability | Without it | Minimum viable version |
|---|---|---|
| Service template | Every service is configured differently | One repository others are generated from |
| Standard build and deploy pipeline | Estate-wide changes are impossible | A shared pipeline definition, not copied files |
| Config and secret delivery | Credentials end up in images and repositories | One managed secret store, injected at runtime |
| Service identity | Internal calls are unauthenticated by default | Short-lived credentials issued per workload |
| Ownership registry | Nobody knows who to wake at 3am | A file per service naming a team and a rota |
| Environment provisioning | Teams wait on a central queue to test | Scripted creation of an isolated environment |
How many people does this take?
Fewer than the term 'platform team' implies, but it has to be somebody's actual job. A small estate can be supported by two or three engineers whose primary responsibility is the paved road. The failure mode is the part-time platform, where a senior engineer maintains the template between feature deadlines, and the template falls behind the services using it until nobody trusts it.
The test of whether the investment is working is the marginal cost curve. If service number twenty took as long to stand up as service number three, the platform is not doing its job and the estate will keep getting more expensive per service rather than less.
This is also the honest reason many organisations should not adopt microservices. Not because the architecture is wrong, but because they cannot staff the platform, and an unstaffed platform means every team spends part of its time reinventing deployment badly. That time is invisible in planning and very large in aggregate.
What does skipping the platform cost?
Divergence, which converts routine maintenance into projects. A vulnerability in a widely used library becomes forty separate pieces of work in forty repositories with forty different build systems, each requiring the owning team's attention and each blocked behind that team's other priorities. Organisations in this state usually discover it during a security response, at the worst possible moment.
It also costs the ability to answer basic questions. Which services use this database. Which are running an unsupported runtime version. Which have no owner because the team that built them was reorganised. In an estate built on a shared template these are queries; in a divergent estate they are surveys.
The clearest measurement available is to pick a real dependency and ask how long it would take to get every service onto a patched version of it. The answer is a direct measure of platform maturity, and it is usually the first time senior stakeholders understand what the architecture actually costs.
Should you build this or buy it?
Buy the infrastructure, build the template. Container orchestration, secret storage, CI, image registries, metrics and tracing backends are all commodity, and building any of them internally is a way to acquire an unfunded product with one customer. The part that is genuinely yours is the paved road: the service template, the pipeline definition, and the small set of shared libraries that make instrumentation and authentication automatic.
Where teams get this wrong is by building an internal developer platform as an abstraction over the managed one, hiding the underlying tools behind a bespoke interface. It works while the two people who wrote it are present. After that it is an undocumented layer between engineers and the tools they could otherwise read the manual for.
A reasonable rule: your platform should be thin enough to explain in an afternoon, and it should be possible for a team to bypass it in an emergency without help. If neither is true, the platform has become a second system to maintain and it will compete with the products for attention.
Common questions
- Do you need a platform team for microservices?
- You need the platform work done by someone whose job it is, which for a small estate can be two or three engineers. The failure mode is a part-time platform maintained between feature deadlines, which falls behind the services using it until nobody trusts the template. If the work cannot be staffed, every product team spends part of its time reinventing deployment, which is expensive and invisible in planning.
- What does a new microservice need before it can go to production?
- A repository from a template, a build producing a scanned image, a deploy pipeline with rollback, somewhere to run, runtime configuration and secret delivery, a service identity for authenticating internal calls, ingress with a certificate, a provisioned and backed-up database, instrumentation wired to shared backends, health endpoints, an alert routed to a named rota, and a recorded owner. Roughly fifteen decisions, best made once.
- What is a paved road in platform engineering?
- A supported default path where the correct way to build and deploy a service is also the easiest. Teams that follow it get pipelines, instrumentation, secrets and alerting without configuring them; teams with genuinely different needs can leave the road and take on the consequences. It differs from a gate, which requires central approval and recreates the coordination the architecture was meant to remove.
- How do you tell whether your platform investment is working?
- Compare how long the twentieth service took to reach production with how long the third took. Microservices are a bet that the marginal cost of the next service approaches zero, so a flat or rising curve means the bet is being lost. A second measure is how long it would take to move every service onto a patched version of a shared dependency.
- Should you build an internal developer platform?
- Buy the infrastructure and build only the paved road. Orchestration, secret storage, CI, registries and telemetry backends are commodity, and rebuilding them internally produces an unfunded product with one customer. Build the service template, the shared pipeline definition and the instrumentation libraries. Keep it thin enough to explain in an afternoon and possible to bypass in an emergency without help.
