Stefan Tilkov explained in his presentation at microXchg 2018, held in Berlin, a series of patterns and antipatterns in microservice projects from his perspective, especially noting that some of the patterns he considers to be good patterns other people may see as antipatterns and vice versa.
The talk began with a discussion that microservices is a pattern where we design modules as separate deployment and operational units, with large degrees of freedom for their implementation. Enforcing communication over a network creates a boundary between modules that promotes encapsulation, thus making it harder to violate how modules were designed to interact and collaborate.
For Tilkov, co-founder of INNOQ, the consequences of using microservices includes isolation, autonomy and flexibility, but he noted that when building modular software along with his definition, there is no real need at all for microservices. However, since we often fail to design large-scale modular software effectively, we still need the microservices pattern.
Evolutionary Architecture
Instead of creating the right architecture from the start when building a system, you can create an "Evolutionary Architecture" that is constructed for adaptability and can be changed to become the right one at a particular point in time. For Tilkov, the approach in such an architecture includes:
- Separation of large domain into what he calls "islands of change"
- Design for replacement, not for reuse
- Minimizing of shared dependencies, with a focus on autonomy and redundancy instead of on reuse
One advantage is that it enables experimentation, for instance using A/B testing.
Distributed Monolith
Tilkov’s first antipattern was the "Distributed Monolith", or microservices gone bad, which he described as:
A system made up of arbitrarily sized, tightly coupled modules communication over network interfaces
For Tilkov this is often a hype- or conference-driven architecture lacking a focus on the business domain. Common consequences using this pattern include:
- Ripple-effect of changes
- Complex environment
- Hard to understand and maintain
At the negative extreme this can become a mix of technologies and frameworks that nobody can manage.
Decoupling Illusion
In Tilkov’s experience, teams often introduce microservices in order to be more flexible and able to quickly adapt to changes. "Decoupling Illusion" is an antipattern in which you split a system up in modules but due to lack of domain knowledge you haven’t solve the fundamental problem — isolating stakeholders and business requirements from each other. Instead you have created modules that now get requirements from two or more stakeholders, and which are dependent on other modules. These modules then have to evolve and be deployed together.
Micro Platform
An antipattern orthogonal to the previous is the "Micro Platform", in which you standardize all internal/operational service aspects into a framework and force all teams to use it. A problem you now have is a technical dependency in every single service, and one stakeholder that is interested in all services. The primary motivation for this antipattern is the goal of standardization, which probably looks reasonable — especially early in a project — but it also creates the need for coordinating new features and updates across multiple teams. To mitigate this, Tilkov recommends that the usage of the framework should be optional.
Entity Service
An "Entity Service", for example an order service, may look like a reasonable and useful service in a retail business. The problem with this antipattern is that all services with an interest in that service will also force their needs onto it, thus causing the entity service to end up being a mix of all interests from all clients using it. Tilkov claimed that often this entity service is not needed at all; its responsibilities belong in other services with their own view of an order. He claimed that the only reason it’s being created is the appearance of "order" in the name, and referred to the ideas of an enterprise data model (EDM) where you try to create a common definition of an order.
DDDD and SCS
Tilkov often meets clients that have complex business applications composed of different parts — bounded contexts. When these contexts are combined with microservices you end up with the "Distributed Domain-Driven Design (DDDD)" pattern where communication typically is asynchronous, maybe using business events, with data redundantly stored. These services are loosely coupled and more autonomous while the size of each service often is as big as a bounded context. For Tilkov the key motivation for this approach is to enable separate evolution.
Self-Contained Systems (SCS) is similar to the DDDD pattern, the difference is that each service also contains its own UI component, with a light-weight integration of the services often done in the frontend. This minimizes the infrastructure needed, and for Tilkov this is the best suited model for decoupling development teams.
Monolith
Tilkov’s final pattern is the "Monolith", which he believes is still ideally suited for many cases, like a single small team. It’s a standard application with straightforward development, is easy to refactor, and does not contain any artificially introduced distribution:
A highly cohesive, tightly integrated, single unit of deployment application
Summary
In his presentation, Tilkov focused on the size of services, and the challenges of getting this sizing correct. He believes that an architecture composed of 2,000 things sitting next to each other will be hard to understand. Therefore, he is advocating a little more structure on top of that, by grouping or clustering. He summarized by emphasizing that none of the patterns are the right model — they all depend on your context. The solution chosen should always be driven by the domain and desired business benefits. He also points out that if possible you should strive for an evolutionary architecture that can grow with your requirements.
The presentations at the conference were recorded, some are already published with more to come.
