Every service needs an amount of technical “plumbing” in its implementation. It needs the ability to retrieve configuration values and secrets. It needs to connect to the data stores, message buses, and other services it depends upon. It needs to emit logs and operational metrics. Teams also need build scripts and CI/CD pipelines that allow each service to be tested, packaged, deployed, and operated.
However, when each service is being built by autonomous teams, working independently, there is a tendency for these basic technical capabilities to be re-implemented by each team. The Green team have their implementation for service discovery, the Yellow team have a different implementation, and the Red team have a third, even if they’re all using the same tech stack.
Each team is wasting time on boring technical glue - time which would be much better spent on building product functionality. The question is, how do we avoid each team re-inventing the same wheel, while still empowering those teams with autonomy?
One fairly common solution is to establish a Service Template - a “Hello, World” service which includes a standard implementation of all the platform plumbing that each service needs. When a team needs to create a new service they start with a copy of this Service Template. This means that all such services inherit a common and consistent implementation of platform capabilities. However, teams are still able work independently on their services after they’ve been stamped out from the template.
There are a variety of benefits in re-using this technical plumbing across different services built by different teams.