How to Recognize Whether the Creation of a New Microservice Should Have Occurred Already

If your situation exhibits the following characteristics, then you probably already needed another microservice:

  • • The service can only be sensibly developed further as a Maven multimodule project or a Gradle multimodule project.
  • • Tests have to be divided into test groups and have to be parallelized for execution since the runtime of the tests surpasses five minutes (a violation of the “fast feedback” principle).
  • • The configuration of the service is grouped by domain within the configuration file, or the file is divided into single configuration files to improve the overview.
  • • A complete build of the service takes long enough to have a coffee break. Fast feedback cycles are not possible anymore (a violation of the “fast feedback” principle).


As the example of the registration microservice illustrates, it is a significant challenge to let a microservice remain a microservice and not give in to the temptation of integrating new functionality into an existing microservice due to time pressure. This holds true even when the functionality clearly belongs, as in the example, to the same domain.

What defensive steps can be taken to prevent the erosion of a microservice? In principle, it has to be as simple as possible to create new services, including their own data storage. Frameworks like Spring Boot, Grails, and Play make a relevant contribution to this. The allocation of project templates like Maven archetypes and the use of container deployments with Docker are additional measures to simplify the generation and configuration of new microservices as well as their passage into the production environment as much as possible. By reducing the “expenditure” required to set up of a new service, the barriers to introducing a new microservice clearly decrease as does the temptation to implement new functionality into existing services.

< Prev   CONTENTS   Source   Next >