In preparation for the upcoming microXchg conference, taking place over the 16th and 17th February in Berlin, InfoQ sat down with Uwe Friedrichsen and Adrian Cole and discussed functional service design, the new challenges with observing a distributed system, and what the future holds for the microservice architectural style.
Key takeaways from the talk with Uwe Friedrichsen, CTO at codecentric, and Adrian Cole, Software Engineer at Pivotal included:
- 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 eningeering 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.
The full transcript of the interview can be read below:
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: Adrian, speaking of moving fast (and not breaking things), how must traditional approaches to system observability evolve in order to provide valuable insight into the operation of distributed applications?
Cole: Monitoring and logging systems need to evolve in ways that reflect current software architecture and those practicing it. For example, there's a narrowing of scope from microservices down to functions and this has an impact both technical and cognitive. For example, the windowing and delivery of metrics can be problematic if they cannot capture short-lived managed functions.
Cognitive burden must be (and is being) addressed, too. For example, we add distributed transactional context to the operations emitting error logs, and then overlay these with more context to further explain them. It is a tough task, as evolution needs to be balanced against system or cognitive overload.
InfoQ: We’ve already heard Uwe talk about the use of “microservice” frameworks like Spring Boot (and go-micro, Seneca.js); so how easy is it to implement observability within a modern development stack?
Cole: So, I'm doing a talk at microxchg on Distributed tracing with Zipkin, and that will show a bit of Java and Spring Boot. It is pretty easy to add "sleuth", which is Spring Boot's distributed tracing plugin, led by an ever earnest Marcin Grzejszczak. Using start.spring.io, you can literally click on words like Zipkin and have a decent chance of success. Judging by blogs I see popping up, I suspect people find it easy enough.
On golang, I've not heard much about micro and tracing, but Peter Bourgon’s go-kit bundles support for tracing via a library interface project named OpenTracing. Documentation suggests appdash and Zipkin work out-of-box. The latter is further ensured by Bas van Beek, who is Zipkin's resident golang Champion.
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 re-learn 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.
InfoQ: Finally Adrian, thinking about the future of the microservices style, what are your thoughts on the value of open standards within this space, and also on the creation of organisation/foundations that steward these?
Cole: This is your toughest question! We use the words open and standard very loosely in practice, which is why this is tough to answer. For example, there are a lot of small working groups prefixing the word open to things, and each have wildly different charters, definitions of openness and what output is appropriate. There are also standards that don't put the word open on them, and have levels of output that seem to rival formal groups like IETF. For example, I'm pretty impressed with what the reactive streams group have done, and if you look at their website the only mention of the word open is "open an issue"!
Back to the point, there is high value standardizing things which became a commodity, and where fragmentation, lack of fairness or interop causes end user value loss. Foundations and Organizations are an asset to those creating standards, as standards by definition are things that require long-term diverse buy-in if to be taken seriously. That doesn't mean standards don't start off scrappy, nor that they can't transition from scrappy to formal when needed, or even that scrappy standards can't succeed. This is just my two pence...
InfoQ will be covering new from the microXchg conference that runs over the 16th and 17th February in Berlin. Further details and the schedule for the conference can be found on the event website.
