Microservices are valuable, but to break things up properly creating the right boundaries we need to understand our business and its processes Jeppe Cramon stated in a presentation at the Microservices Conference in London.
Jeppe, working with large scale system integration at Tigerteam, is sure there is a lot of value in componentizing and believes Microservices is a good opportunity to evaluate what was good with SOA, what we misunderstood and what can we learn and improve. But he also believes we need some guidelines to help us build better software.
Microservices should be valuable, meaning that the value must exceed the cost of building and operate it. If we follow the principle that everything runs in its own process we have to pay the penalty of serialization, communication, monitoring, etc. which adds a significant amount to the cost of building the service. Jeppe believes that if we build too small services there is a big risk that things that belong together, and should be kept together, are separated and what's left of coherence disappears. We also get both communication and layered related coupling together with temporal and behavioural coupling. If we go down this path of building small services we are just building a distributed monolith.
To break things up, we want things to be a bit smaller and easier to comprehend, but we also need cohesion and loose coupling, so we need to understand the business as a process and how data is flowing, thus enabling us to build the right system and finding the right boundaries. Many of us have been trained in thinking in entities and structure models and this is where we get into problems. We start small but as we add things suddenly the model have grown to the size where we can't see the responsibilities or the boundaries. The mental capacity required to understand a large model is very high, and in Jeppe's experience this is where monolithic systems typically get into problems.
Looking at an online retail system as an example we find different areas, e.g. purchasing, sales, inventory, shipping, each with specific and unique needs and that typically don't overlap much. This allows us to split the domain into a macro architecture, the reason being to depict the stable parts of the architecture and use it to align business capabilities, or bounded contexts, with services. Domain-Driven Design (DDD) doesn't enforce problem and solution domain alignment for bounded contexts but one reason for aligning services with business capabilities is that business capabilities are remarkably stable, if we get them right chances are they will not change. What's inside can change a lot, but at a logical level it’s stable. Jeppe emphasizes though that we must beware of separating into services too quickly; cross-boundary refactoring can be expensive.
In Jeppe's opinion a service is the technical authority for a business capability, which means it's the owner of all data and business logic that support this capability everywhere it's needed. Looking at the deployment model a service must then be deployed in every system where the service' data is required. This gives us a single source of truth for that capability, and alignment between business and IT, ensuring we can have autonomy which removes any need to call other services.
With a service being the technical authority for a specific business capability it can get quite large so we need something smaller and Jeppe states that a service is implemented by microservices, defining microservices as being a division of a service along transactional boundaries. While services are logical deployable units it doesn't mean they have to be deployed individually. We should design for distribution but take advantage of locality. With a system made up of multiple microservices there is often no reason for them to be in individual processes.
Services are for Jeppe the cornerstones when we talk about business capabilities, with Microservices an implementation detail, an advantage since they are less stable. Being small with a single purpose, they have the benefits of being easy to write, test and replace.
In conclusion Jeppe defines Microservices as a Service-Oriented Delivery Model, focusing on service alignment with business capabilities making them as small as possible, but also as big as necessary. Services are implemented as a set of Microservices that are logically deployable. Doing this Jeppe believes Microservices will help us achieve some of the things SOA has promised us.
The Microservices Conference is the first on the subject arranged by Skills Matter, in London. Next year’s conference is open for registration.