After working with different technologies for many years, Jeppe Cramon believes that the most important aspect when designing systems is understanding the business domain we are working in. We should focus on identifying the bounded contexts and the business capabilities, and design services and microservices using this knowledge. In a presentation at the recent Micro CPH conference in Copenhagen, Cramon talked about his experience in working with distributed systems, the last five years working with microservices, and the underlying principles and patterns he today sees as beneficial for successfully creating microservices based systems.
10 - 15 years ago, we often used portals and portlets. Cramon, founder of Cloud Create, notes that despite their problems, such as a heavy technology and inflexibility, one advantage was that the user interface (UI) was componentized with a page divided into small views, each handled by a small service. This meant that many developers could work independently on the same page and that each of the views were easy to change due to their decoupled nature.
For Cramon, these ideas evolved into SOA and larger services. A common problem was that services were dependent on other services, and one failing data or entity service could bring many dependent services down. Ensuring consistency was hard, commonly requiring distributed transactions which don’t scale. Another challenge in distributed systems is when synchronous communication is used, for instance RPC, REST or SOAP. It lowers our tolerance for faults and hinders performance. Cramon summarizes his experience with:
Friends don’t let friends use layered SOA.
Based on his experience with these and other technologies throughout the years, Cramon believes that we should focus on the business domain and finding the boundaries within it, in order to be able to define the services for the solution. What he wants to achieve is problem domain and solution domain alignment. The business should be reflected in the code — enabling the business and IT to speak the same ubiquitous language. Business capabilities are often very stable, and he refers to Bill Poole who back in 2008 wrote about business capability alignment and other concepts that later became synonymous to microservices.
Cramon prefers smaller models with clear data ownership and to use business events to drive business processes. This keeps the services decoupled and enables the use of an orchestrated or choreographed business process to ensure that each workflow is handled correctly. He notes that only events relevant for the business should be published; events internal to a service are an implementation detail.
Describing today’s world of microservices, Cramon borrows his definition of a service from Udi Dahan in his article The Known Unknowns of SOA. Dahan defines a service as the technical authority for a given bounded context or business capability. It is the owner of all data and business rules in this context, and Cramon emphasizes that this applies everywhere and that this way we can form a single source of truth for the context.
Regarding service design, Cramon notes that a service represents a logical responsibility boundary and therefore needs to be deployed everywhere its data is needed. He notes that a service’s logical responsibility and physical deployment don’t have to be one-to-one, and refers to Philip Krutchen and his 4+1 view of architecture.
To achieve this, we need more fine-grained blocks, and for Cramon this is where microservices fits in. With a service implemented by one or more microservice, microservices becomes individual deployable units with their own endpoints. One example is dividing a service along transactional boundaries when using CQRS; the write model can then be handled by one microservice, and the read model by one or more other microservices.
There is no need for all microservices to be individually deployable. Another concept, also from Dahan, is autonomous components which stand for logical deployable units. This means that they can, but don’t have to be, deployed individually. Cramon points out that we should design for distribution but take advantage of locality when possible. Distribute only when needed, for example due to scalability issues.
Many services can be deployed on the same physical server and in the same application. Cramon notes that applications and services are different concepts; an application boundary is both a process boundary and a physical boundary, while a service is a logical boundary. This means that different parts of services can be deployed to different tiers; some parts can be deployed to the web tier while other parts are deployed to the application service tier. But it also means that the same service can be deployed to multiple tiers or applications.
Cramon summarizes by emphasizing that a service represents a logical boundary and is an aggregation of different autonomous components. He sees applications as mashups of different services, which means that a service must own its UI components to achieve full decoupling.
Most presentations at the conference were recorded and will be available over the coming weeks.