Relearning Functional Service Design for Microservices: Uwe Friedrichsen at microXchg
The opening talk of the microXchg microservices conference was delivered by Uwe Friedrichsen, and discussed the core concepts of “Resilient Functional Service Design”. Key takeaways included: microservice developers should learn about fault tolerant design patterns and caching, but not utilise them to mitigate fundamentally bad (overly-coupled) system design; understanding Domain-Driven Design (DDD) and modularity is vital; and aim for replaceability of components rather than reuse.
Friedrichsen, CTO at codecentric, began the presentation by stating that the goal of software development is to deliver business value, and for this to be realised the software must be run in production and be (highly) available. Modern architectural styles, such as microservices, mean that everything is now distributed (most likely spanning at least a local area network), and therefore failures within the system are normal and not predictable.
Developers should familiarise themselves with fault tolerant design patterns, such as circuit breakers, bulkheads, timeouts and retries, which has been popularised by Michael Nygard’s “Release It!” book. Caching, although useful, should be deployed with care, and not used simply to overcome bad system design, such as a long activation path involving many dependent services.
Friedrichsen presented a series of ‘foundations of design’ for microservices (pictured below), which included a series of design principles focusing on high cohesion, low coupling, and separation of concerns. This principles are especially crucial across system boundaries, and even though the theory has been well documented in the 70s by David Parnas (PDF link), it is still often misunderstood.
Domain-Driven Design (DDD) is a useful tool, but many developers overly focus on the static context model of domain, something Friedrichsen refers to as ‘Entity DDD’. The dynamic behaviour of the system is often more illustrative of the business activities, domain events, and flow of data.
Don’t start with the static domain model, the magic is in the dynamic behaviour of the system.
Microservice developers should not strive for reusability, and instead aim for replaceability. Quoting Fred Brooks, Friedrichsen discussed the promise of software reuse that has been chased by developers for many years. Brook’s suggested that work effort required to create a reusable component (over one that is fit for purpose for a single case) is typically multiplied by three, meaning that any return on investment for reusability is only seen when a component has been used without modification at least four times.
The communication paradigm used within a microservices system also greatly influences the functional service design, and Friedrichsen suggested that care should be taken with upfront architectural choices that may limit future modification and extensibility.
The concluding message and core takeaway from the talk was that developers and architects need to relearn functional service design when implementing distributed systems like microservice, as the properties of these systems expose and multiply the effects of design issues we have known about for many years.
The video for Uwe Friedrichsen’s talk, “Resilient Functional Service Design”, can be found on the microXchg conference YouTube channel.