MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Platform and deployment · Foundation

Service Template

The Service Template pattern gives teams a maintained starter project for each kind of component, with the chassis, build pipeline, deployment and standards already set up, so a new service is production-ready from its first commit.

Last updated

Use it when

  • Teams create new services regularly.
  • Services built by different teams have drifted apart in how they log, deploy and alert.

Avoid it when

  • You create a new service a few times a year. A checklist and a good example repository may be enough.

Goes with

Microservice ChassisHealth Check APIExternalized ConfigurationYou Build It, You Run It
Test yourself

What is the Service Template pattern?

A service template is a starter repository, or a generator that creates one, for a kind of component: a backend service, a BFF, a micro-frontend or a mobile feature module. It includes the agreed language and framework, the microservice chassis, a CI/CD pipeline, deployment manifests, dashboards, alerts and an example endpoint. Teams start from it with one command, and it is often called the golden path or paved road.

What problem does the Service Template pattern solve?

When every team sets up services by hand, each one takes days to reach production and comes out slightly different: different logging, a missing health check, no alerts. Those differences make every service harder to operate and every move between teams harder. A template makes the right setup the fastest one.

How do you implement the Service Template pattern?

  1. Offer one template per kind of component and per blessed stack, not one for every possible technology.
  2. Include the chassis, pipeline, deployment, health checks, dashboards and an example test, all working on day one.
  3. Create new services through a single command or a developer portal, which also registers the owner in the service catalogue.
  4. Treat the template as a product with an owner, a changelog and feedback from the teams who use it.
  5. Plan how existing services pick up template changes, for example through automated pull requests.

When should you use it?

  • Teams create new services regularly.
  • Services built by different teams have drifted apart in how they log, deploy and alert.

When should you avoid it?

  • You create a new service a few times a year. A checklist and a good example repository may be enough.

What do you gain?

  • New services reach production in hours, not days
  • Consistent operations across teams
  • Standards are adopted by default, not by policing

What does it cost?

  • The template needs an owner and ongoing work
  • Services drift from it after they are created
  • Teams on other stacks get less help

Who usually owns the Service Template pattern?

Platform team. A platform team builds and runs this once, as a self-service product that every product team uses without rebuilding it. See how teams map to layers and patterns.

What are common mistakes with the Service Template pattern?

  • A template copied once and never updated, so every service starts from an outdated setup.
  • Mandating the template instead of making it the easiest path, so teams route around it.
  • Packing everything anyone might need into it, so a simple service starts with a dozen unused dependencies.

Service Template in practice

Real-world example

Spotify

Spotify's infrastructure risked becoming a wilderness of competing technologies and orphaned dependencies, and starting a new piece of software took a lot of setup.

Spotify built Backstage, a developer portal it later open-sourced. Its Software Templates let an engineer pick a template and get a repository, a first deployed build and a starter project with the organisation's practices built in, so a new project starts in minutes instead of hours.

Source: Cloud Native Computing Foundation accepts Backstage as a Sandbox project (Spotify Engineering, 2020)

Example decision record
Context
New services take a week to reach production and come out with different logging, deployment and alerting.
Decision
Offer a maintained template per kind of component and blessed stack, created with one command and owned by the platform team.
Consequences
  • New services are production-ready on day one.
  • The template needs ongoing ownership and a way to update existing services.

Test yourself on Service Template

Platform and deploymentfoundation

Teams take about a week to get a new service into production. Each one sets up its own pipeline, logging and dashboards, and an audit finds a third of services have no health check. What would help most?

4 questions involve this pattern. Practice all of them →

Done with Service Template?

Saved in this browser only. See your progress →