What Are Microservices

In the past I've mentioned the term microservices several times, assuming that everyone knows what they are, but I have received a few messages asking about them, their advantages, and so on. 

In this post, we’ll take a look at what microservices are. It’s important to point out that what we call microservices is actually a programming architecture, so it applies to any web language, whether it’s C#, Java, PHP, or JavaScript frameworks. 

1 - What is a monolithic application?

Before we start discovering what the microservices architecture is, we need to understand that these didn’t appear out of nowhere, but are an evolution of monolithic architecture.

This architecture is based on having a single application for the entire system structure. 

This architecture has several problems, and most of them are much "bigger" than the benefits it can bring us. 

The main characteristic of a monolithic application is that the entire project, and therefore its code, is all in the same place. Everything is tightly packed together. 

1.1 - Advantages and disadvantages of monolithic applications

This brings us several disadvantages:

• The codebase gets very large, which might not seem like a big deal, but it becomes a problem when loading it onto your computer, for example, and of course, it makes it much harder to update or manage. 
• A minor change, such as a single word on the front end, means we have to deploy the entire application. And if the project is very large, this can take minutes, or even hours depending on the size. It’s common in companies that use monolithic architectures to have only one deployment per month, or even less, and that deployment is very critical because if the application is down, customers cannot access it, and so on.
• Scaling or replicating this kind of application is not impossible, but it’s extremely costly and complicated, especially because you probably only need to scale about 1% of the app, but since everything is together, you must replicate the whole thing.
• Migrating to another technology or using other technologies is almost impossible. If the app is from the year 2000 and was originally written in .NET Framework 1, it’s nearly impossible to see it migrated to .NET Core, and let’s not even mention using Blazor, for example. 

But there are also a few benefits, not many, but still: 

• Deployments, though critical, are usually "simple", you just have to do a single deployment. If the app is massive, that’s a problem, but for mid-sized apps, everything might be deployed in about 5 minutes.
• There are no partial system outages. One of the problems with microservices is that one might be down or the network might not work, so things can take longer. With monoliths, you don’t have this problem: the whole app functions the same way, and if it’s down, nothing works. 

Note: Keep in mind I’m always speaking in terms of a work environment. For a small personal project, like a blog, there’s no need to use microservices. 

2 - What is a microservice

Now that we’ve seen what a monolith is and we understand it’s an early-century architecture, let’s move on to the most common one nowadays: microservices.

Note: There are others, like serverless architecture, but that’s a topic for another post.

We can say that microservices architecture is a style in which we create small services that communicate with each other, mainly using lightweight protocols like HTTP. Usually through APIs, commonly, REST APIs.

One of the main characteristics of microservices is that each one has (if it uses it) its own database, file system, and so on. The idea is for these services to be independent (at the logic level), which can lead (and does lead) to duplicating information in some cases. 

Personal note: When we were starting the project I’m working on now, the development manager said, "Don’t worry about duplicating information, do it ten times if needed; storage space is cheap, what’s expensive is transferring data."

2.1 - Characteristics of a microservice

Before talking about the advantages and disadvantages, I want to explain what you should think about before creating a microservice. 

A - Responsibility: We need to consider what our microservice will do. The easiest way (in my opinion) to detect what part should go in which microservice is by following business logic (in this case, the company).

Looking at the example in the previous image, we see that there’s a microservice for movies info, another for series, and another for actors.

And there are other microservices that depend on them.

B - Preventing complete outages: One of the big strengths of microservices is that we can make them work partially (obviously not in every case).

What do I mean by this? Again, let’s use the previous image as an example.

Imagine the "movies" microservice is down. Therefore, "new releases" and "continue watching" will be partially down, but "most watched series" will be fully functional.

That means on our home screen, users should be able to see all information related to series, even if the rest is unavailable. 

When developing microservices, we should build them assuming that one might not work, and, if possible, allow the system to run without it. 

2.2 - Advantages and disadvantages of microservices

Just like in the case of monolithic architecture, there are both advantages and disadvantages, but in this case, the advantages are much greater. 

2.2.1 - Advantages of microservices

• Micro: The word micro in microservices isn’t there by accident, the idea is that these are very small services in terms of code, which makes them easy to modify.
• Being "micro" means their logic is much simpler, so changes are easier to make.
• Microservices are independent, which means deployments are done individually. If you need to scale a specific service, you only scale that one.
• You can build each microservice using whichever technology you need most.
• As seen in the previous image, just because one microservice is down doesn’t mean the application can’t work, parts of it can still be available. 

2.2.2 - Disadvantages of microservices

• A system distributed as microservices is usually harder to understand. The more microservices you have, the more complexity and interdependencies you'll find.
• Keep in mind that microservices communicate over the network, which means there could be some latency between calls.
• Figuring out what should be a microservice or what should go inside an existing one is the most difficult part of this architecture.
• It’s crucial to have a good logging and monitoring system for the flow and the application, because an error in one microservice can show up in another, making debugging difficult.  

Conclusion

In this post we’ve seen the difference between monolithic architecture and microservices architecture.

Depending on your requirements, you’ll use one or the other, but in most cases today, you’ll choose microservices.

Finally, we’ve seen the pros and cons of microservices architecture.