Why go for Microservices?

Gerald de los Santos
6 min readOct 22, 2020

--

Photo by Andrea Piacquadio from Pexels

Microservices is an architectural approach to designing applications in a way that is modular, easy to deploy, and scale independently.

How can we benefit from switching to it?

A lot of the benefits of the microservices design pattern applies to any application, even the traditional web application. It just happen to benefit more from rapid deployments and continuous delivery. It also push the limits of most automation tools and infrastructure in place today to the limits.

Let’s try and understand the concept of a service first.

A service is a piece of software which basically provides functionality to other pieces of software within your system. The other pieces of software could be anything from a website to a mobile app, or a desktop app, or even another service which uses another service in order to carry out a particular type of functionality. And the service basically provides functionality to these applications.

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms (HTTP resources).” — James Lewis and Martin Fowler, Thoughtworks

Differences in paradigm

Some of the developers are using Monolithic architecture in which all parts of the application are packaged together in three-tiered application architecture. This means that the presentation, business and persistent layers are packaged together. In Microservices architecture, it follows domain-driven design which are sub-divided into small parts to identify the service that has a problem and be able to fix it without issues to other parts.

The figure below shows that Monolithic architecture is packaged as one while the Microservices architecture separate each services to make the application easily organized, developed, and maintained.

Monolithic and Microservices Architecture

The table below shows the solution of Microservices architecture to the problem that may be encountered using Monolithic architecture. It describes the advantages of Microservices over Monolith architecture.

Advantages of Microservices over Monolith Architecture

Why would you consider monoliths? Let’s look at the advantage and disadvantages

MONOLITHIC APPROACH

Advantages

  • The biggest advantage of a monolithic architecture is that there is a lot of overlap in most apps — such as logging or security functions — and these are easier to handle in monolithic architectures. If everything runs on the same app, then it is easy to connect the components.
  • Lower operating overhead costs: as it is a single, large-scale application, the logs, monitoring and tests only have to be set up for one application. This means that the app is generally easier to provide.
  • Performance: here, too, there may be advantages, as there is no communication between the individual services.

Disadvantages

  • Fixed coupling: monolithic architectures tend to interlock and entangle more tightly as the application evolves, making it difficult to isolate the individual services for one purpose, such as independent scaling or code maintenance.
  • Higher complexity: monolithic architectures are much more difficult to understand, as there are always dependencies and effects that cannot be identified clearly by focusing on a specific server or controller.
  • As a monolithic application grows, so does the associated code base, which overburdens the development environment each time the application loads. This reduces the productivity of the developers.
  • As the application runs on EAR/JAR/WAR, for example, it is difficult to change the technology afterwards. Changing the code base of a monolith is complicated because it is always difficult to predict how this will affect the functionality of the entire monolithic application.
  • If a single function of the monolith or a single component fails, the entire application fails. If an application contains functions such as payment, login and history, for example, and only one of the functions starts to use more processing power, then this will hinder the performance of the entire application.
  • Those who want to scale monolithic applications can only do this by distributing the same EAR/JAR/WAR packages on additional servers. This is known as “horizontal scaling”. Each copy of the application on additional servers uses the same number of underlying resources, making it an inefficient design.
  • Monolithic architectures influence the development as well as the deployment of the applications. When applications grow, it is even more important to break the applications down into smaller components. As everything is so tightly interrelated, developers are unable to work independently on monolithic architectures or provide only their own modules. Rather, they are dependent on others and this slows down the development time.

While monoliths might be just fine for some businesses. Let us consider looking at Microservice approach and see if this will cater your needs:

MICROSERVICE APPROACH

Advantages

  • Easier understanding. Split up into smaller and simpler components, a microservice application is easier to understand and manage. You just concentrate on a specific service that is related to a business goal you have.
  • Independent components. Firstly, all the services can be deployed and updated independently, which gives more flexibility. Secondly, a bug in one microservice has an impact only on a particular service and does not influence the entire application. Also, it is much easier to add new features to a microservice application than a monolithic one.
  • Better scalability. Another advantage of the microservices approach is that each element can be scaled independently. So the entire process is more cost- and time-effective than with monoliths when the whole application has to be scaled even if there is no need in it. In addition, every monolith has limits in terms of scalability, so the more users you acquire, the more problems you have with your monolith. Therefore, many companies, end up rebuilding their monolithic architectures.
  • Flexibility in choosing the technology. The engineering teams are not limited by the technology chosen from the start. They are free to apply various technologies and frameworks for each microservice.
  • The higher level of agility. Any fault in a microservices application affects only a particular service and not the whole solution. So all the changes and experiments are implemented with lower risks and fewer errors.

Disadvantages

  • Extra complexity. Since a microservices architecture is a distributed system, you have to choose and set up the connections between all the modules and databases. Also, as long as such an application includes independent services, all of them have to be deployed independently.
  • System distribution. A microservices architecture is a complex system of multiple modules and databases so all the connections have to be handled carefully.
  • Cross-cutting concerns. When creating a microservices application, you will have to deal with a number of cross-cutting concerns. They include externalized configuration, logging, metrics, health checks, and others.
  • Testing. A multitude of independently deployable components makes testing a microservices-based solution much harder.

Why would I go for Microservices?

These are the reasons why:

  1. Need to respond to change quickly: Adopt to changes so that the product will still be marketable.
  2. Need for reliability: If one part breaks, it would not break the entire system.
  3. Business domain-driven design: Changes will not affect other services if the other parts changed.
  4. Automated test tools: Used to test integration between services.
  5. Release and deployment: There is a centralized tool for deploying multiple services.
  6. On-demand technology: No need to deploy the software to physical servers. Instead, have a server which provides a cloud of virtual machines.
  7. Need to embrace new technology: Going from one technology stack to another technology stack.
  8. Asynchronous communication technology
  9. Simpler server side and client side technology

--

--

Gerald de los Santos
Gerald de los Santos

Written by Gerald de los Santos

a Software Developer, loves singing, poetry, writing, spirituality, happy life and doing good stuff

No responses yet