In preparation for the upcoming microXchg conference, running 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.
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 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 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 need 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), and 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.
