I mean, yes, you’re not wrong about that, in fact, that’s not where the confusion happens.
We tend to think about “microservices” as small, very logic-focused services that deal with, usually, one responsibility. However, if we look at Martin Fowler’s definition of Microservices — and you know, he’s a very smart guy, so we usually like to know what he thinks — you’ll notice we’re missing a very small, yet key, trait about microservices: decoupled.
Let’s take a closer look at what we’re calling “microservice”. This term gets thrown around so much these days that is getting to a point where it’s exactly like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.
Truth be told, from 99% of the interviews I take as a manager, when I ask about microservices I get responses about REST APIs. And no, they’re not necessarily the same thing.
And by definition, REST APIs alone can’t be microservices, even if you split them up into multiple smaller ones, each taking care of a single responsibility. They can’t, because by definition for you to be able to use a REST API directly, you need to know about it.
As a related side-note: There are two types of REST developers (meaning devs creating REST APIs):
- The ones that implement as many features about REST as they think they need. Meaning that they might care about resource-oriented URLs if they feel like it, and maybe they will worry about their APIs being stateless since it’s not that hard to implement. But this type of developer will 99,9% of the time ditch the HATEOAS (Hypermedia As The Engine of Application State). In other words, self-discoverability of the structure of the API is no longer a feature, the client and the server have a hard-coded contract between the two of them.
- The ones that follow the REST standard to the letter. I think I’ve only seen one developer like this in my experience — so if you’re like this, please drop a comment and let’s connect! — . Implementing REST APIs this way can take a lot longer, but the result is a lot better, especially because clients have very little coupling with the server, all they need to know about is where it is and what’s the root endpoint. The rest is done through self-discoverability, very cool.
However, in both cases, the coupling between client and server is still there. You can’t get a decoupled communication JUST through REST, and that is why, if we’re strict with the definition of microservice — and we’re trying to be— they can’t be called like that.
So instead, let’s loosen up the belt of definition, leave ourselves some wiggle room and call these services: miniservices.
So we can define a miniservice as:
Small-ish enough services (usually APIs) to be considered “mini”, they still need to take care of only one single responsibility, however, we’re not too worry about the “decoupled with the client” part.
Granted, the less coupled they are the better it’ll be for future changes, having a dynamic client will definitely help adjust faster and without much impact upon changes on the server. That’s definitely a plus, but it’s not part of our definition.