Page Title Here

Below is a list of all the blog posts you are posting that your
visitors might be interested in...

< Go back

Expert story

Microservices, what's in a name?

Pieter Herroelen
Pieter Herroelen

Pieter is an experienced software developer. He focusses on the details as well as the bigger picture. He likes his coffee black and feedback loops short.

Microservices are all the rage right now. It's an architectural style which promises fast delivery and robust, scalable systems. Some people say it's SOA 2.0. For a thorough introduction, I recommend reading this article by James Lewis and Martin Fowler. You could say that microservices are the love child of Continuous Delivery and DDD. Unfortunately, someone made a mistake when registering the baby. They got the name wrong.

The name "microservices" seems to imply that it is the size of these services that matters. But in fact this is a mere byproduct of trying to get to easily evolvable services by splitting them up until they match one business capability. The size of your services is not a good metric when assessing how well you've implemented microservices. This subject reminds me of what Bill Gates once said:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

-- Bill Gates

"My services are more microservices because they have fewer lines of code." Are you kidding me? Don't get me wrong; a microservices architecture ís made up of many small services. But compared to the traditional SOA service implementations I've seen, in some ways they are in fact bigger.

A microservice is centered around one cohesive business capability with everything that's needed for it. So it could expose both a REST API and some UI fragments, for instance. This stands in stark contrast with the service layering approach I've come across many times.

And because we want a robust, scalable system, microservices also get additional responsibilities compared to a typical service implementation. Concerns like routing, configuration, discovery and observability are all handled decentralized. This is what they call 'smart endpoints, dumb pipes'. Each microservice needs to be smart enough to do their part. Of course you're not going to implement these capabilities for every service. In fact, the code of your microservice is not going to be much bigger. There are more and more libraries and tools that you can use for fault tolerance, configuration, service discovery, monitoring ... . You don't have to build all of this yourself. Even so, at run-time your microservice will have to perform these duties.

So microservices aren't defined by their size. What should you worry about instead of how big your services are? I'll dig a little deeper in future blog posts.