The strength of the pack, Microservices (I)


The strength of the pack, Microservices (I)

30 March 2020

This article is part of a series of articles on methodology, architecture and new technologies written with the goal of sharing part of the processes developed by our high-performance teams at Mindden.

This article is part of a series of articles on methodology, architecture and new technologies written with the goal of sharing part of the processes developed by our high-performance teams at Mindden.


You may have heard of microservices oriented programming, or how this new paradigm proposes distributed architectures in autonomous subsystems. In this article we will try to explain in a simple way what this model consists of and how it can contribute to software development projects, through a short introduction to the world of microservices.


In the traditional approach of development, software is comprised of a client part and a server part. This means that one part runs on the client side and the other part runs on the server side. When you need to “consume” the application in a new way, this will be resolved by creating different clients, one client for each type of device on which the application can be run.

At this point, what happens with the server part? Well, we face a series of common problems;

  • When there are many customers “consuming” it, it overloads.
  • When there are few, it works very well but it is oversized in infrastructure and cost.
  • When it needs to be updated, it remains out of service fast.


This is traditionally known as a Monolith, for being large, stable and very unmanageable.


This is a well-known and recurring problem against which IT departments all around the world have been fighting for years. Improving this paradigm has been a priority for many reasons:

  • The difficulties of updating a monolithic application as it is a unique code.
  • The problems of any new deployment requiring to relaunch the entire application.

One of the solutions mostly adopted by the global development community has been to implement models which “break” that monolith into smaller autonomous parts; for the moment we will not go into more detail.


Why can this paradigm be applied so successfully to software development? because it is actually one of the most successful strategies in the natural world, dividing the problem or facing the solution in a distributed way. Let’s think of, just like ants coordinate to carry a load hundreds of times heavier than them, or a school of fish groups to confuse the predator, distributing the services previously coupled to a single unit, will make us find ourselves in a new scenario.


This scenario offers an opportunity and disadvantages, we summarize it briefly:


The main disadvantages.

  • Increased time of data in transit.
  • Great discipline is required in maintaining contracts for communication, otherwise we may undermine cohesion.


On the other hand, this new paradigm has several advantages.

  • The server part is technologically heterogeneous. Always maximizing performance and development agility.
  • Due to its scalability it only replicates the most congested part, improving infrastructure costs.
  • A refactor is always on one part and not on the whole.
  • Having parts in different repositories prevents conflicts.
  • It offers greater ease when implementing perimeter security since only some parts are exposed.
  • The single-responsibility principle prevents code duplicity.
  • Deploying a part will always be faster than deploying a whole.
  • Less coupling


Mindden has been working on this type of paradigms for many years and we have faced projects of all kinds, some in which a distributed architecture strategy is the best option and others where maintaining a coupled development basis can help us achieve our goals.


That is why the best option is always to know as many solutions as possible, to maximize ROI and the benefit provided to all stakeholders in the process.


For all these reasons, and quoting the sentence attributed to Julio Cesar: “Divide and conquer”, we will see you soon in MICROSERVICES (II).