It can be easy to fall into bad patterns when moving to microservices, according to Chris Richardson, microservices consultant and founder of the transactional microservices startup Eventuate. The important thing is to recognize the mistakes you are making and address them.

Some common mistakes or anti-patterns Richardson sees organizations fall into are:

Distribution is free: Developers treat their services like programming language-level modules, which results in high latency and reduced availability. Instead, developers should pay attention to how their services interact with each other and ensure they can handle requests without relying on another service.

Shared databases: According to Richardson, developers have a hard time wrapping their heads around the fact that there is no longer a single database. Databases should not be accessed by multiple services in a microservice architecture because it requires too much coordination across teams. Instead, tables should be accessed by a single service and services should collaborate through APIs.

Unencapsulated service: This creates a large API that doesn’t encapsulate a whole lot and basically negates the whole idea of a microservice, Richardson explained. The solution is to have an encapsulated service that hides as much implementation as possible and enables loosely coupled teams. For instance, an iceberg service encapsulates significant business functionality, is small, and bundles data and behavior.

Distributed monolith services: A distributed monolith pattern creates two or more services that implement the same concept. Richardson explained that things that change together should be packaged together.

RELATED CONTENT:
With microservices, more isn’t always better
Microservices gone wrong

On the non-technical side of things, some problems Richardson sees are that organizations:

  • Believe microservices will solve all their problems instead of using microservices to solve a particular problem, such as accelerating development.
  • Set a goal of adopting microservices when accelerating software delivery is the real goal.
  • Attempt microservices when they are not ready with the necessary skills such as clean code, object-oriented design and automated testing.
  • Create a bunch of services just for the sake of having a large number of services, which creates unnecessary complexity.
  • Adopt microservices without addressing process, policies and culture such as siloed teams, manual testing and monthly deployments.