Hi Clement, tell us who you are and what lead you into microservices?
Once upon a time, I was doing a lot of OSGi development. OSGi was bringing two excellent characteristics: modularity and dynamism. Each part of the system was developed as a group of bundles exposing services that evolve independently at runtime. However, there was no free lunch, these two characteristics were not coming without a cost, and it was often required to understand the classloading mechanism of each library, be sure you don’t have dependency conflicts… So without a Spartan discipline, it can quickly derail.
At that time, using distributed systems to get modularity, dynamism, and independence was too expensive. Even having multiple JVM processes on the same host was considered expensive.
Time passed. Devices became more powerful. The private and public Cloud infrastructure made it easy to get new machines. What was considered too expensive became affordable. So here we go, to get modularity, dynamism, and independence we traded OSGi complexity for … distributed systems.
That’s how I came to microservices. The 10,000 feet view looks like a paradise. Each part of the system is now developed as a completely independent process, exposed to the rest of the system using a lightweight protocol. Every part can evolve at its own pace.
However, when we zoom in, things get darker. That’s why I’m interested in microservices because if it worked nicely, it would not be fun anymore.
What will you be talking about at Voxxed Days Microservices?
My talk is about reactive and from where it comes. It arises from the darkest parts of microservice systems and distributed systems, from fool’s bargains that have been made to simplify how things work. The talk explains why blocking, and synchronous communication is a bad habit for microservices, and how by embracing asynchronous message passing, you can build better systems. But, let’s not stop here, the talk also shows it. It demonstrates, using Quarkus and Apache Kafka, how you can build an elastic, resilient, and responsive system effortlessly.
A few years ago Microservices were just about synchronous invocation with service discovery and circuit breakers all over. Today it looks like reactive Microservices is the new thing. How do you see these two models evolving?
Microservices are, by nature distributed systems. For years, developers have built monoliths where everything was running in the same process. So, it looked ok to apply the same patterns in microservices. Except that… it’s leading you to a world of nightmares.
Distributed systems are very different from a monolith, and the patterns you were successfully using in a monolith can be harmful in a distributed system. The most common flaw is relying on synchronous communication, generally HTTP-based. Using blocking IO is not only going to limit the concurrency of the microservice, but it’s also going to make the overall system brittle. Of course, you can try to use patches, but there are short-term fixes. Fortunately, there are solutions, and not new, solutions that exist for 25 years that have proven to be very efficient with microservices such as messaging technologies.
HTTP is not going to disappear anytime soon, and it is handy when interacting with different systems. However, inside your system, it can become a significant bottleneck.
Shortly, we are going to see lots of improvements in both messaging and remote communications areas. The usage of binary protocols (like protobuf), the generalization of non-blocking protocols, HTTP/3 are going to change the face of microservices again. So no, we are not going to get bored for a while…
Good, see you soon then
#ReactiveManifesto #GraalVM #Quarkus #ReactiveProgramming
My contact information
Twitter: @clementplop
LinkedIn: https://www.linkedin.com/in/clementescoffier
GitHub: https://github.com/cescoffier