Hi Nicolas, tell us who you are and what lead you into microservices?

Hello. I’ve been a developer/architect for most of my professional life, mainly in the Java/Spring ecosystem. Even at that time, I was interested in the other side: operating, monitoring, etc. what today would be called DevOps. Last year, I steered my career in another direction and became a Developer Advocate.

I’m working for a company called Exoscale. We are a European Cloud Provider, offering Infrastructure-as-a-Service resources. There’s no denying Cloud hosting is gaining a lot of traction, and the microservices architecture is particularly well-suited to Cloud hosting. Hence, using my experience as a developer, I worked a lot on the integration of different themes that make sense together: configuration management, resilience across services, logging, monitoring, etc.

 

What will you be talking about at Voxxed Days Microservices? 

My talk is about resilience: when one migrates from a standard API call to a service call, one can easily believe in the fallacies of distributed computing. Chief among those fallacies is “the network is reliable”. Hence, for some reason, the required service could be unavailable. Fortunately, there’s the timeout; unfortunately, if the caller needs to wait for the timeout, chances are it’s going to be flooded by requests, and be unavailable itself.

In those kinds of architecture, a failure can quickly propagate all over the place, and put the whole system down. For that reason, smart people came up with the Circuit Breaker pattern. Just like a household circuit-breaker protects the electrical system from power surges, the pattern protects the architecture. However, one must be careful as “Circuit Breaker” is quite a general term. Libraries implement it, service meshes implement it. Those are not interchangeable! 

 

Microservices architecture are using more and more asynchronous messaging and streaming, therefore circuit breakers tend to decline. Do you see a trend here, what about the future of the circuit breaker pattern ? 

My personal opinion is that one should be very cautious about trends. Most companies do use microservices. Even worse, most companies are even hardly suited to use them. I love this image from Martin Fowler’s blog:

Microservices offer a lot of benefits, but also have very strong requirements. Most people only see the benefits, and conveniently forget about the requirements… until they come to bite them where it hurts. Likewise, asynchronicity makes it harder to reason about the code, and increases by a non-trivial amount the workload in two areas related to software development: debugging and testing. 

I’m a big fan of continuous improvement myself and I believe that trying to implement asynchronous microservices from day 1 is a sure recipe for disaster. Remember that Twitter started with Ruby on Rails. This pragmatic no-nonsense way should be the way to go for every company which wants to be successful. Start with a monolith, then if necessary, migrate to macro-services, then refine them (if necessary) to microservices, then introduce asynchronicity where it makes sense, etc.

 

Good, see you soon then 

 

#devops #resilience #circuitbreaker

 

My contact information

Twitter: https://twitter.com/nicolas_frankel

Blog: https://blog.frankel.ch/

GitHub: https://github.com/nfrankel