In today’s tech jargon, a common word you may hear is microservice. It’s a word that can be meaningful but hard to implement or understand in depth.

Don’t trust me? Well, let’s warm up. 

Let’s start here: what is a microservice? 

Most people will simply state the obvious and define the “meaning of the word”. So their answer might be:

Well, a microservice comes from micro (from ancient greek: micros – small), and service.

And yes, technically you’d be right. 

But, let’s get a little bit deeper here. If we were to ask for more details about it, could you provide some? How could you do it if we ask you to break a whole monolith system down to microservices?

Now things are getting tricky and the “meaningful word” goes away. 

So here it goes: what are microservices?

First, let’s start with some analogies. 

In a recent conversation with someone, the topic moved from talking about a developers job and then, the following happened:

  • “How can you explain the definition of microservices to a non-technical person?”
  • “Well, have you ever seen ‘Despicable Me’?”
  • “Yes!” 
  • “Microservices are like the minions*. They basically do one specific thing at a time and they are able to talk together (in a weird manner) but that can lead you to get a solution. So yes, most of the apps you use on your day-to-day are backed up by tons and tons of minions doing just one single thing at a time.”

With that being said, let’s take this topic seriously by giving you an earnest definition of this.

“Microservices are an architectural and organizational approach to software development where we have a set of small and independent services that communicate with each other over APIs” (Microservices, AWS, 2023). 

At first glance, we can start to deduct a couple of pros from this definition. Perhaps after reading the definition, you’ll say:

Well, it sounds like if microservices are independent and small, if one of them goes down perhaps the other ones should be up and running, doesn’t it?

Yes, that’s one of the advantages that we can find quite easily. However, if you want to have a better set of microservices pros, here are some more:

  1. As microservices are small modules, they’re intended to be focused on doing a set of scope-limited tasks. For example, we can have a microservice just for invoicing, another to do the login and user creation, and another to read the customers, items etc.
  2. Being small makes it easier to maintain and keep all the logic decoupled and isolated from other code changes that might impact it. 
  3. (Just to keep it on the list) Microservices are independent, so basically if one of them goes off, all of them will keep running
  4. Microservices are small and also easily duplicated, they can be scaled out and in a piacere, being this something that can be cost-worth in long term. 

Everything sounds great, right? Are microservices the holy grail for everything? Shoud I always break everything down to become micro-serviceable? 

It depends.

I need to make a hard stop here, despite the usage of it in a big group of top-notch tech enterprises, microservices are not always the best solution.

Even if we already discussed the pros of using this, we also need to walk through the cons of using microservices:

  • Avoid them if you’re writing a small application: Don’t try to get rid of a fly with a sledgehammer. If you are looking to do microservices over a very small app, you will spend more time than expected by getting everything set to make them run.
  • Every single module needs to be tested/deployed: Related to the latest point, we need to ensure that every single microservice is well tested, well deployed, and working well. Perhaps you can skip the test if you want to but I want to paint a picture in your head about the technical debt you might be dealing with. 
  • When we’re looking for microservices, we need to put everything in that way: Let’s talk for example at the DB level – Can you just have one single instance of your database making microservices getting inside? 
  • You have a limited budget: Perhaps we can infer that from the previous point. Getting more means costing more. Period.

To wrap this article up, let me bottom line the whole for you:

Use microservices if:

  • You’re expecting a big flux of traffic and you need to scale-out or scale-in in piacere to find a balance between availability and cost
  • You have some people to work on the testing and development.
  • You’re dealing with a monolith that needs more and more RAM to run your app smoothly.

Use monoliths if:

  • Your app is small or internal. Hence you’re not expecting a big flux of traffic. 
  • You have limited budget or timeframe and just a single server can do the work for you without struggle (if you’re starting to put more and more RAM, that might be the time to hop to microservices)
  • You feel the microservices are way too time consuming to implement.

*This is not the first article in Medium (and I can bet this will not be the last) that explains microservices with minions. Gamesh Samarthyam from Medium is a person that also agrees with us about this thinking. So, take a look at his article if you’re interested.