👋🏽 Welcome back! It's Tebogo, and this week, we're chatting about microservices and why you should, or shouldn't use them.

---

Microservices represent a software architecture style that structures an application as a collection of loosely coupled services. This is the opposite of a monolithic architecture, where an application is structured as a single indivisible unit.

In a microservices architecture, each service is independent and services a specific business use-case or functionality. The services communicate with each other through well-defined APIs either synchronously or asynchronously.

Pros of Microservices

1. Scalability: Having multiple independent services means you can scale different parts of the system independently. For example, if you have a system, a simplified online store, with a UserService, MarketplaceService, and PaymentService and your system started to see an increased load in MarketplaceService, you could scale the specific service independently. This would greatly reduce costs and ensure that resources go where they are most needed.

2. Flexibility: With microservices, you can opt for different tools, languages, or frameworks for each service. It's recommended to be consistent and use the same tool throughout but there are certain cases where one tool is better than others. If most of your services are written in Python and there is a requirement for a new service that needs to do fast processing, Python might not be the right tool for the job but a different language like Rust or Golang might be perfect. Since your services communicate through well-defined APIs, the interfaces matter the most and not so much what happens within.

3. Resiliency: In a monolithic system, a failure in one part of the system most often means a failure throughout the entire system. In microservices, you avoid single points of failure by ensuring that services operate independently. Let's have a look at our previous example. If you have a UserService, MarketplaceService, and PaymentService and your payment provider fails, only PaymentService will be impacted. You users would still be able to do authentication and browse the marketplace.

Cons of Microservices

1. Management overhead: Having multiple services means that you have more services to manage and maintain. Not only that but you'll have more pipelines and production servers to maintain. When a library version you currently use gets deprecated, you will have to update every service's codebase. In a monolithic architecture, this change will only need to be done once.

2. Increased latency: Over the network communication is expensive in time, and sometimes in money. Communication that happens between application classes in a monolith happens between network interfaces in microservices. The increased latency can reduce the responsiveness of your application. The network calls also add a point-of-failure as network calls can fail.

3. Data consistency challenges: The biggest issue with microservices, in my opinion, is data consistency. Unlike monolithic architectures, where data is typically stored in a single database, microservices often involve each service having its own database. This approach, as great as it is, makes it difficult to maintain consistency, especially in scenarios where transactions spanning multiple services are required. There are solutions such as the SAGA Pattern but the real issue is in determining when you have a data consistency issue.

Final Thoughts

I think a lot of people have fallen for the hype behind microservices. Microservices are great for fast-paced environments where each domain is handled by an individual team. Teams might move at different paces and use different tools and microservices allow them to do this in isolation.

Do not default to microservices. Ask yourself "Why microservices and not a monolith?". My suggestion for building new systems would be to build modular monoliths. Think of it as microservices within a monolith. Separate and isolate each domain even though everything is all in the same codebase. Using this approach, if parts of your monolith become heavily used and require to be split out, it would be a simple job of moving out that domain into its own microservices and interfacing with it.

---

Do you think microservices are as great as people say they are? Share your thoughts in the comments.

If you found this article insightful and helpful, feel free to share it with your friends and colleagues.

Thanks for reading! 📖