Introduction to Microservices

Introduction to Microservices

If you belong to the Tech-industry or are somehow loosely connected to it, you must have heard a fancy term going around, ‘Microservices’.
As confusing as it may sounds, it is fairly simple but rather an important architecture used by IT giants and even small companies.

Monolithic Architecture: A love-hate relationship.

To learn about microservices, we need to understand why there was a need for such architecture and how it came to be.

Before microservices took over, ‘Monolithic’ reigned over the kingdom of digital architecture.

Monolithic architecture, as the name suggests, is a single Unit, well.. a monolith.

This means that no matter the number of services you create, all of them will be coupled in a singular unit.

Let's say we have a Totally-Not-Uber-like taxi service app that contains numerous services such as Login, Passenger Management, Transactional services, Driver Management, Notifications, Trips

All the above services play a crucial part in the application to function properly.
As mentioned earlier, in this architecture, all of the services are deployed in a single unit and the communication between the services is made accordingly.

Monolith Structure

Deploying such projects was fairly easy, all one had to do was pick the improved/updated ‘Unit’ and place it on the server, replacing the existing ‘Unit’.

These were the go-to architecture in the past, as they were simple and pretty sophisticated, but soon enough, as the code base increased, services multiplied, and their functionality started to take leaps, everything went haywire.

New programmers or even experienced programmers were haunted by the daunting complexities created by interlinked relationships of modules.

With advancements, the number of modules started to increase and the whole structure was difficult to handle due to numerous disadvantages, some of which are:

Testing*:* Even when a single change was made in a module, all the modules that communicated with it were tested to ensure proper synchronization and flow. This made testing a difficult task which often took much more time as the project progressed.

Deployment: Major companies like Google, Amazon, Microsoft, Netflix, etc. deploy multiple changes in a single day. The problem with a monolithic structure is that even for a small change, the whole project was required to be deployed, which made frequent changes and deployment almost impossible and inefficient.

Versioning: There are times when one-version-fits-all is not entirely possible, as some module demands a specific version, which may not allow the other module to function properly. In a monolithic structure, playing around with different versions is as cumbersome as one can imagine. It’s galore of module failures due to compatibility issues.

Slow Development: Normally, modules are segregated among the teams, and specific groups of people create, manage, and improve a set number of modules. However, In this architecture, there is a high possibility of dependency or, even worse, code/logic conflict, which in turn, hammers the development speed.

Microservices: A Ray of Hope!

As cheesy as the header may sound, my fellow programmers who were stuck in a giant mud-ball of monolithic hell would relate to it.

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

Yeah.. that was from amazon’s AWS website.

Well, simply put, many modules/services, are independently deployed in containers (not in a singular unit), which communicate with each other using APIs.

As compared to the previous architecture we discussed, this one is much more flexible and opens a plethora of doors in terms of developmental progress.

As the services/modules are loosely coupled, it makes independent development a cakewalk.

It makes it much easier for teams to create, manage and upgrade their specific modules without breaking the entire software.

There is usually a gateway acting as a central hub for all the deployed microservices. This adds an extra layer of security as all the request-response passes through it. Stuff like encryption-decryption, header checking, and request parsing, all of that can be conveniently done at the gateway without making the code redundant.

Services can also independently communicate with database or third-party service providers

One of the plus points it has over monolithic structure is how easy and convenient it is to determine a failure or a bug, with the help of logging. Custom logging can be written in all the microservices which would then call an API from Log Microservice, which would be responsible for entering the logs in the Database.

Throughout the years, many changes and developments were made to microservices, and many software like Docker and Kubernetes came into the picture. What is Kubernetes can be a topic for another day as it is such a vast and interesting topic that it deserves a separate discussion

Load Balancing: You gotta love it!

Most of us are well aware of the agony one feels when a screen takes way too long to load due to late request-response time.

Sometimes it might be just poorly written and unoptimized code or it can be heavy traffic which may keep the services occupied. This is where load balancing plays its part.

When a service is deployed in a container, that container can be replicated, either permanently or temporarily to keep up with the quantity of traffic. As the name suggests, it ‘balances’ the load by distributing the total workload among different instances of a service. By instances, I mean replicas or duplicates of the service.

Load-Balancing

This prevents uneven and timely responses and bumps up the efficiency by some notches.

But just like with everything that exists in this world, microservice architecture has its own set of advantages and disadvantages.

Advantages of Microservices:

Scalability - Temporary or permanent:

  • Each microservice runs independently and it is easier to cherry-pick a microservice for updates, addition, or removal. Developers can perform these tasks without disrupting the working of other microservices.

  • If there is an increase in traffic for a particular microservice then more resources can be devoted to it and when the traffic eases down, the number of resources can be reduced.

Fault isolation:

  • In a monolithic structure, when a module or a service fails it often becomes difficult for us to pinpoint the actual location of the failure due to excessive inter-module dependency or overlapping services.

  • However, in a microservice architecture, it is less likely that the failure of a single service would affect other services unless and until they are directly dependent on the service that has failed.

  • Due to this, it is possible to exactly pinpoint the service which has failed. Combine it with a proper logging system and you'll get a pretty robust architecture in which module failure can be quickly recognized and fixed.

Outsourcing:

  • Sometimes a business must outsource a specific service to third-party partners to consume, but they are often not able to do so due to security concerns that arise due to the monolithic structure, meaning there is always a possibility that the whole unit would be at the stake of exposure, along with the modules containing delicate and private data.

  • But the independent nature of microservices helps the company to avoid such situations as the services which are needed by the third-party partners can be cherry-picked and outsourced without exposing other services.

Experimental:

  • Unlike monolithic structures, experimenting with them is much easier with microservices.

  • If one wants to roll out a new feature, it can be done pretty easily as this architecture supports rapid deployment, as discussed earlier.

  • If in case users do not like it or the business logic is not up to the mark, the changes for that specific module can be quickly rolled back without affecting the operation.

Ease of Deployment:

  • Rapid deployment is possible as the teams responsible for their service can independently deploy their changes for their specific module without having to deploy the complete project again, which would take longer to deploy and may, in some cases, halt the working of the production build.

Disadvantages of Microservices:

Management:

  • When the architecture grows in terms of the number of services and quantity of API, it becomes difficult to manage and keep track of everything as a whole.

  • It takes skilled engineers or developers with sound knowledge of the structure to handle gigantic microservice structures.

Testing:

  • Keeping in mind the independent nature of the modules, developers cannot test the working of the system as a whole from their machine.

  • Hence, Unit testing is much more feasible as compared to integration testing.

Need for DevOps:

  • DevOps is the team that is responsible for the deployment and management part of the microservices.

  • This makes having a good DevOps team very crucial to successfully deploying the changes on the server(s).

This was a quick introduction to get a basic understanding of what a microservice is and how it can be useful if used correctly. The rabbit hole is much deeper than one can imagine. There is so much more to microservices but in order to fully understand the advance stuff, getting the basics clear is very crucial.
Hope this tiny article helped you in a way or two!