Key Takeaways
- The key ideas associated with microservices are the properties that support independence of the rest of the application landscape and quick evolvability. This is often ignored by implementors.
- Monitoring and logging systems need to evolve in ways that reflect current software architecture, and this has an impact that is both technical and cognitive.
- Many things learned in a classic software engineering education about how to slice functionality (such as "Don't Repeat Yourself") does not work for distributed systems, like microservices.
- The term "microservices" itself will probably disappear in the future, but the new architectural style of functional decomposition is here to stay.
- There is high value in standardizing things that become a commodity -- and where fragmentation, lack of fairness or interoperability causes loss of end user value.
At the microXchg 2017 conference, held in Berlin, Germany, Uwe Friedrichsen discussed the core concepts of “Resilient Functional Service Design” and how to create observable systems. Friedrichsen believes that in order to develop effective systems, microservice developers must: learn about fault tolerant design patterns and caching, but not utilise them to mitigate fundamentally bad (overly-coupled) system design; understand Domain-Driven Design (DDD) and modularity; and aim to design 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 must learn about the fundamentals of resilience:
The fundamental and concepts and patterns of system resilience
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.
Uwe Friedrichsen’s foundations of service design
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.
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.
Friedrichsen suggested developers should dismiss reusability, and instead strive for replaceability
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 those being created by microservice architectures, as the properties of these systems expose and multiply the effects of design issues we have known about for many years.
InfoQ sat down with Friedrichsen, and discussed further the challenges with designing resilient and observable service:
InfoQ: Uwe, what is the most challenging issue for the current batch of organizations implementing microservices?
Friedrichsen: That they are doing microservices in the first place.
"Microservices" have become a popular, mainstream term and everybody who uses Spring Boot or alike claims to do microservices. Do not get me wrong: there is nothing wrong about Spring Boot, but writing a standalone application that exposes some HTTP interface does not mean that you write a microservice.
The key idea with microservices are the properties that support independence of the rest of the application landscape and quick evolvability. Unfortunately, based on what I can observe, people put too little effort into those properties that define a microservice.
Microservices are an architectural style that help you to move fast. You need to move fast in IT if your company lives in a fast moving market and if the IT needs to support business to move fast. But even then, a lot more than just an architectural style is needed to move fast as IT.
The problem of those hyped trends like microservices is that people often try to pick them up even if they are not an adequate solution for their situation. If your IT does not seriously try to become faster, you probably do not need microservices. You can still use Spring Boot (it is fun, after all), but you should not call it "microservices".
InfoQ: Uwe, moving now towards development patterns, can you recommend a technique for encouraging developers and architects to think about functional service design?
Friedrichsen: If I knew one, I would sell it for a lot of money and be real rich… But again, let us be fair. I see three factors that make it hard to get developers and architects to think about functional service design to the extent they should:
1. It is hard, really hard, and even after 40+ years of software architecture and design it is poorly understood.
A lot of people then mention DDD (Domain Driven Design) and DDD indeed is a good starting point. Still, only knowing the patterns is completely different from being able to create a sound design for your current business problem using those patterns - especially if you have your product manager or product owner sitting over you all the time, urging you to be "more productive".
Also, everything we learned in our software education about how to slice functionality, e.g., functional decomposition, DRY (Don't Repeat Yourself) or create re-usable functionality, does not work for distributed systems, like microservices are. If you use those design best practices, you will end up with an extremely poor design that will haunt you badly in production. Basically we have to re-learn design for distributed systems and based on my personal observations, we still have to learn a lot about how to do that right.
2. The real issues of IT are swamped by more attractive side-shows.
New frameworks, programming languages, endless debates about how to do this and how to do that, tons of opinionated people who try to tell you if you don't do this or that, you are doing it all wrong. We drown in shiny new stuff and opinions. Go to a conference, read an IT magazine or just look at your Twitter timeline and you know what I mean. And all of this promises a lot more fun than trying to learn how to do design well.
3. We lose our collective memory every five years.
Based on my observations, we face a new generation of developers coming from university (or wherever else) about every five years. From a different perspective, this means that we lose our collective memory also every five years. These people do not (yet) know the talk or article that has been an eye-opener for you several years ago. They have to relearn all that on their own from scratch, every single person who starts in IT.
What makes things harder with respect to "timeless" topics like functional design is the fact, that in IT, "new" is considered "valuable" and "old" is considered "worthless". We are a fast moving business, aren't we? What value could knowledge that is five, 10 or even more than 20 years old possibly have? And even if some people eventually understand that not all old knowledge is worthless, that we keep telling and forgetting the same stories over and over again, it mostly remains unheard of in the vast numbers of new developers joining IT every year.
InfoQ: You mention the rapid change of people within the IT industry - what does the future hold for the microservices architectural style itself?
Friedrichsen: If I am really frank: I have no idea. The term "microservices" itself will probably eventually be burnt as all hype terms, after a majority of vendors, consultants and people who just want to adorn themselves with the new cool thing have picked them up. The architectural style, on the other hand, is here to stay. Actually, the style was not new when we started to call it "microservices"; it existed for many years. It just was updated based on the advances in IT and then called "microservices". And probably after the next update, the style will be called something different.
In the near future, we maybe will see some more differentiation of the microservice style. Not everybody needs all properties of a "pure" microservice style. Many people might get along with just a subset of the microservice style properties in order to satisfy the needs they face.
But to be honest: in the end, I have no idea.
The full video for Uwe Friedrichsen’s talk, “Resilient Functional Service Design”, can be found on InfoQ.
About the Interviewee
Uwe Friedrichsen is CTO of codecentric AG, where he focuses on resilience, scalability, and the IT of (the day after) tomorrow. Uwe has traveled the IT world for many years and is always in search of innovative ideas and concepts. Often, you can find him sharing ideas at conferences or in his many articles, blog posts, and tweets.
