Lately, a new SW architecture model based on microservices has been imposed. It has gained a lot of strength given its capabilities and the novelty compared to previous models. Today, almost all customers want their applications based on microservices, or migrate their existing ones to this architecture. But is it good practice to apply microservices at will? What advantages and disadvantages does its use generally present?
As we discussed in a previous article, microservices are a new architecture model where we separate the different functionalities of a product into more compartmentalized spaces that are self-sufficient and remain connected.
This model has come to replace what is known as the “monolithic” architecture, where all the project operation’s rests on the same code or system.
Both design methodologies have advantages and disadvantages, strengths and weaknesses that we must evaluate depending on the context in which it is used.
In the case of microservices, although it is a useful architecture in a large number of occasions, most IT architecture projects usually require a monolithic application or SOA as a base.
Why? Normally our clients will want their users to all connect to the same system, application or network. It serves to unify methods, projects and communication, and many are used to having everything in one place. This does not mean that it is always the right decision.
We can discern between the benefits and disadvantages of microservices:
As we have already said before, each company and client is a world. Everyone has different needs that will require a design process and strategy.
Fortunately, many customers also often want very similar features if they are looking for the same service or are in the same industry. After all, if it works for your competition, why shouldn’t it work for you?
Creating an orientation guide, both for your programmers and for your clients, is very useful. A guide where you explain the most common needs of each type of project and link them to one of the two work systems. In order to be able to make the best decision from the beginning and facilitate the process for your client.
For example, ERPs and CRMs are usually monolithic applications due to their use in specific systems (work computers). While microservices are being used more for applications with various types of devices in mind and a large number of connections (IoT, web, mobile,…)
With these elements in hand, we should be able to recommend to our customers whether or not a microservices architecture is suitable for their needs. It is risky to base all the programming work of our clients on a single technique. Especially when it is not adequate in all the cases that exist in the different work sectors.