If the Service template and Microservice chassis are the solution, what is the problem? §

---

Last week, I had a great interview with Sven Johann for the CaSe: Conversations about Software Engineering podcast. The topic of the interview was the Service template and Microservice chassis patterns. As part of the preparation for the interview, I reviewed the two patterns on Microservices.IO and I was surprised to see that the both patterns were missing an essential element: the problem statement. A situation that reminds me of the number 42 from The Hitchhiker’s Guide to the Galaxy.

About the Service template and Microservice chassis patterns §

Here are the thumbnail definitions of the two patterns.

The Service template pattern thumbnail:

Quickly create services by cloning a service template, which is a runnable, template code base that implements the logic that is common to each service.

The Microservice chassis pattern thumbnail:

Improve maintainability of services cloned from a service template by extracting the logic from the template into a microservice chassis framework.

This diagram shows the structure that results from applying these patterns:

The key elements are as follows:

• Microservice chassis - a framework implements the bulk of the logic common to each service
• Service Template - a template codebase that uses the Microservice chassis
• Service - one or more services that are cloned from the Service Template

What problem do these patterns solve? §

Both pattern descriptions contain all of the essential elements (Context, Forces, Solution, Consequences, Related pattern) of a pattern except for the problem statement. So what is a concise way of stating the problem? My first thought was a suitable problem statement would be “How can a team quickly create a new service?”. While this is simple and concise, it’s somewhat vague. What does it mean to “create a service”?

If you read the context that’s shared by the two patterns, it describes the challenges with creating and maintaining a service’s code base. In particular, how to setup up and maintain the the service’s build logic and the code that implements common cross cutting concerns. But why is that a worthwhile problem to solve?

It’s important to reduce the time spent setting up this logic, because it enables the team to quickly start working on the service’s business logic - its reason for existing. What’s more, it’s important to solve this problem in a way that simplifies the future maintenance of many services. Consequently, I thought the following is an accurate problem statement:

How can a team quickly create and setup a maintainable code base for a production-ready service so they can start developing its business logic?