monolithic vs microservices 1

Information Technologies and Business Processes


Microservices architecture, or simply Microservices, is a different method of developing software, which has grown in popularity in recent years. For many developers it has become a preferred way to build business applications. Due to its scalability, this architectural approach is considered particularly ideal when you have to enable support for a range of platforms and devices (spanning web, mobile devices, Internet of things, and portable devices) or simply when you are not sure which type. of devices will need to be supported in the future.

Although there is no standard and formal definition of Microservices, there are certain characteristics that help us identify the style. Basically, the Microservices architecture is a method of developing structured software applications based on a set of small, loosely coupled, modular services that are independently implemented; in which each service executes a unique process and communicates through a lightweight and well-defined mechanism to fulfill a functional objective.

Use: Advantages and Disadvantages

Microservices are not a magic bullet, and implementing them will expose communication, teamwork, and other issues that may have previously been implicit, but are now forced to come out into the open. How every tool has its advantages and disadvantages in its use, this is how it is:


  • The Microservice architecture gives developers the freedom to independently develop and deploy services.
  • A Microservice can be developed by a fairly small team.
  • The code for different services can be written in different languages ​​(although this is discouraged by many professionals).
  • Easy integration and automatic deployment (using open source continuous integration tools like Jenkins, Hudson, etc.).
  • Easy for developers to understand and modify, therefore, it can help a new team member get productive quickly.
  • Developers can make use of the latest technologies.
  • The code is organized around business needs.
  • Starts the web container faster, so deployment is also faster.
  • When a change is required in a certain part of the application, only the related service needs to be modified and redeployed; there is no need to modify and redeploy the entire application.
  • Better Fault Isolation – If one Microservice fails, the other will continue to function (although one problem area in a monolithic application can put the entire system at risk).
  • Easy to scale and integrate with third party services.
  • There is no long-term commitment to technology.
Read More:  Microservices: new trends in software development


  • Due to the distributed implementation, testing can become complicated and tedious.
  • The increase in the number of services can create information barriers.
  • The architecture offers additional complexity as developers must mitigate fault tolerance, network latency, and deal with a variety of message formats, as well as load balancing.
  • Being a distributed system, it can lead to duplication of effort.
  • When the number of services increases, the integration and management of complete products can get complicated.
  • In addition to the various complexities of monolithic architecture, developers have to deal with the additional complexity of a distributed system.
  • Developers need to do more to implement the communication mechanism between services.
  • Handling use cases that span more than one service without using distributed transactions is not only difficult, but also requires communication and cooperation between different teams.
  • The architecture generally results in higher memory consumption.
  • Partitioning the application into Microservices is largely an art.


Microservices architecture is an approach to developing an application made up of a set of small services, each one running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are based on business needs and can be implemented independently, using fully automated implementation machinery. There is a minimum of centralized administration of these services, which can be written in different programming languages ​​and use different data storage technologies.

A better way to understand what Microservices are, is to compare it with the monolithic style: a monolithic application built as a single unit. Business applications are often built into three main parts: a client-side user interface (consisting of HTML and javascript pages that run in a browser on the user’s machine) a database (consisting of many tables inserted in a common, and generally relational database administration), and a server-side application.

The server-side application will handle the HTTP requests, execute the domain logic, retrieve and update the data from the database, and select and populate the HTML views to be sent to the browser. This server-side application is a monolith, a single logical executable. Any change to the system involves creating and deploying a new version of the application on the server side.

Read More:  What is Microservices Architecture? Advantages & Disadvantages

microservicios vs monolitico 2

Components by Services

A component is a unit of software that is independently replaceable and upgradeable. Microservices architectures will use libraries (libraries), but their main way of creating a component of their own software is to divide themselves into services. Libraries are defined as components that are linked to a program and called by in-memory function calls, while services are out-of-process components that communicate with a mechanism such as a web service request or remote procedure call.

A main reason for using services as components (rather than libraries) is that services can be implemented independently. If you have an application that consists of multiple libraries in a single process, a change to any component involves redeploying the entire application. But if that application breaks down into multiple services, it can be expected that many changes to the service will only require the service to be reloaded. That is not absolute, in some cases it will have to be reinitialized.

Another consequence of using services as components is a more explicit component interface. Most programming languages ​​don’t have a good mechanism for defining an explicit public interface. Often times only documentation and discipline prevent customers from breaking a component’s encapsulation, leading to an overly tight coupling between components. The services make it easier to avoid this by using explicit remote calling mechanisms.

Organization Around Business Needs

When looking to break up a large application into parts, management often focuses on the technology layer, excluding the User Interface, server-side logic, and database teams. When teams are separated in this regard, even simple changes can lead to a project taking longer and the same with the approval of your budget.

The Microservice approach is based on decomposing the functional needs of the business into many services, which solve a small part of the whole, so that each of them can solve a complete function, operate independently, but with precise communication mechanisms between them. In such a way that this set of services covers the entire functional requirement.

Read More:  Web architecture: SOA vs Microservices, applications & differences

The teams for developing Microservices are cross-functional, including the full range of skills required for development: systems design, programming, user experience, database, and project management.

Relationship with SOA

When Microservices are analyzed, it is common to wonder about how they relate to Service Oriented Architecture (SOA). This is because the style of Microservices is very similar to that of SOA. The problem is that SOA has many different things, and therefore in practice Microservices and SOA are different frames of reference.

The typical SOA model usually relies heavily on EBS data buses as opposed to Microservices. SOA focuses on imperative programming, while Microservices occupies the reactive programming style. On the other hand, SOA preferably uses an external database, while Microservices usually occupy NoSQL or micro-SQL databases (those that can be connected to conventional databases). But, the real difference between SOA and Microservices has to do with the methods that architectures use to achieve the integration of the set of services.

How they are built

Each Microservice can be implemented in any programming language [3] and can use different infrastructures. Advanced technologies are the communication medium of Microservices (synchronous, asynchronous, etc.) and the protocol they use (REST, messaging, etc.). Based on the service requirements, the communication mechanism and its protocol must be chosen. The architectural component can be categorized into:

  • Load Balancer.
  • Service Discovery
  • Database / Cache.

For more information on the tools for the programming of Microservices and how companies are using them is the Stackshare site.