Service Template

Even among strong engineers you can often hear the following take:

Well, microservices — that’s where everyone tinkers however they like, picks whatever they want, and somehow solves problems on their own.

Unfortunately, this is a common misconception. Let’s talk about the benefits of applying the Service Template¹ pattern at the company level.

Service Template provides a unified structure and a shared project scaffold. That dramatically reduces cognitive load on developers: every mechanism, from handling incoming requests to publishing and consuming messages on a shared bus, will be the same across services.

Distributed tracing, error logging, and metrics collection are also part of the service template. By using shared, battle-tested mechanisms, developers don’t have to solve these problems from scratch in each service.

A good service template — even if it has variants in different programming languages — makes life easier for the operations team. By providing a unified build artifact that always listens on the same port and is configured by the same set of environment variables, services built from the template share a single deployment pipeline. There’s no need to maintain different sets of pipelines for different services, the count of which can run into the hundreds or even thousands.

It’s not just the pipelines: deployment manifests too — whether helm charts, kustomize resources, or ansible playbooks — will be the same across all services.

Beyond the technical points, there’s another less obvious upside: with a uniform approach like this, it becomes easier to move people from one team to another. The reasons can vary. Someone gets tired of working on their own project and wants new experience. Somewhere, a team needs a temporary boost from one or two developers. Or you need to form a new team to work on a new task.

With this approach, productivity may dip only in the context of getting up to speed on a new domain — every tool and approach stays the same as before.

Finally, let’s try to formalize the requirements for a service template:

• Conforms to the 12 factors.
• Uses a single set of environment variable names for configuration.
• Supports one programming language.
• The build artifact listens on the same port.
• The template ships with pre-configured:
  • error handling and collection;
  • logging;
  • distributed tracing.
• Defined and reused:
  • mechanisms for handling incoming and outgoing requests;
  • mechanisms for publishing and consuming messages on the shared data bus.

If you use multiple programming languages, you should build a separate service template for each language. But remember: too broad a stack of languages and technologies hurts quality and productivity.

That brings us to another important topic — Technology Radar, or TechRadar — which we’ll cover in the next post.