Microservices Fundamentals

In today's world, we are hearing a lot about microservices and related stuff. And believe me, they all sound very popular and important because people will give wired looks to you if you say, you don’t know what these popular tools and system are.

Even, I heard many tech people saying that the monolithic approach is bad and we should not follow it, although many of them even don’t know why what and how it’s bad or why microservices are good.
So, before going into deep of microservices, let me clarify that firstly, please try to understand and get away from the hype from your mind of thinking of bad or good. These are the approaches that can be followed and the most important for you is to know what your/project requirement is. Because both the approaches have there own pros and cons.

Takeaways from this article are :

• Which approach needs to be preferred and when?
• What are Microservices?
• Big-picture of Microservices
• Benefits of Microservices
• Challenges of Microservices

How to choose your route towards Monolithic/Microservice?

While choosing the architecture, you need to be very clear about the system, you gonna work on. I will take an example and try to make this point clear.

Question: I want to make a new product/startUp, what to choose?

Answer: I will personally suggest taking the path of monolithic here because you are at the very beginning level then later you can switch into a microservices architecture. I know, this seems not convincing to you at this moment of time … so ask yourself,

• How many people gonna work on the system
• Do you have sufficient resources
• How you will split the responsibility among teams/ people
• Do you have skilled people who can set up and manage
• Is it a good time to put this much high expense?

— If your answer is yes, feel free to go with microservice.

I said NO because at the beginning it will be too hard to handle the complex microservice architecture.

What are Microservices?

Microservices is an architectural style where autonomous, independently deployable services collaborate together to form a broader system/application. Isn’t it so simple? It sounds simple but it's not until and unless you understand how it is decomposed(check the below diagram).

Also, if I go with the literal meaning of microservice than it means small services.

But now the question arises, how small a service should be, to name it as microservices. Truly speaking, the fact is nobody knows how small it should be 🤣. That’s the problem so the answer is: decompose the service as much as it can work independently (basic rule of microservice)

Big-picture of microservices:

Microservice Architecture

If you want the same architecture to be understood in layers/ patterns, refer to the below diagram:

Microservice Architecture based on patterns

Microservice Architectural Patterns :

1. Decomposition patterns

• Decompose by business capability
• Decompose by subdomain

2. The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.

3. The API Gateway pattern defines how clients access the services in a microservice architecture.

4. The Service Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.

5. The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.

6. Testing patterns:

• Service Component Test and Service Integration Contract Test
• Circuit Breaker
• Access Token

7. Observability patterns:

• Log aggregation
• Application metrics
• Audit logging
• Distributed tracing
• Exception tracking
• Health check API
• Log deployments and changes

8. UI patterns:

• Server-side page fragment composition
• Client-side UI composition

* Note: I tried to explain most of these patterns as component of microservices in my previous articles

Benefits of Microservices:

• Decompose Application into small services: Breaking down the application into smaller pieces, each microservice can be owned by a small development team and is much easier to understand and work on. And these teams will be responsible for the complete service, they are owning. This result in making microservices light-weighted.
• Independent Microservices: A good rule of thumb for the size of a microservice is that it’s small enough to be thrown away and rewritten if necessary.
• Independent of Technology: Microservices allow us the freedom to adopt new technologies without needing to upgrade everything in one go and the flexibility to choose the right tool for the job. E.g. One service is written in object-oriented while others in the functional programming language.
• Separate Database: Each service owns its own database, which means no centralized database dependency.
• Loose coupling: When we create microservices, their loose coupling means that we can deploy them individually, and this is a huge benefit since it’s lower risk than upgrading everything in the entire system in one go, and it also helps us to achieve zero-downtime deployments. And that’s because while we’re upgrading an individual microservice, it’s quite possible for the rest of the system to carry on running. Microservice architectures enable teams to deploy with much greater frequency.
• Increased Deployment Frequency: Rather than waiting months for the release, changes to individual microservices can be pushed to production as soon as they’re ready, and it’s even possible to deploy microservices multiple times a day.
• Agility: As the features/task go very frequently on production, the system progress can be measured and also help in adapting the rapid changes coming to business development if, any.
• Scalability: Microservices give much more control over scalability. We can scale out each microservice individually depending on its need, which is more cost-effective.

[Note: And these are just some of the reasons why microservices is becoming popular, particularly for very large cloud-deployed systems.]

But, unfortunately, microservices do come with some challenges.

Challenges of Microservices:

1. Development: Need to identify all the dependencies. Complete build of the system means all the services are built.
2. Testing: All the Microservices needs to be tested in order to ensure that the output of one service is the desired input for another service. Contract driven testing needed for such assurance.
3. Monitoring and Logging: All the Microservices need to be monitored continuously and logged with alerts if, the matrix is going wrong.
4. Backward Compatibility: It's super important to maintain versioning and backward compatibility as the system is so complex.

[Note: Microservices are the best option when it comes to heavy systems.]