Microservices, when and when not?


Microservices, when and when not?

The technology market trend

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?

What do microservices bring me? What are they taking away from my productivity?

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:

Benefits of microservices 

  • Delineation of “boundaries” between modules: Microservices reinforce the modular structure, which is particularly important for larger, multi-department teams.
  • Standalone Deployment: Simple services are easier to deploy, and because they are self-contained, they are less likely to cause failure of the entire system when one of them fails.
  • Technological diversity: With microservices you can combine multiple languages ​​and technologies, frameworks and data storage technologies.

Disadvantages of microservices

  • Distributed: Distributed systems are more difficult to program, as remote calls to action are slow and always at risk of failure.
  • Maintaining consistency: Maintaining strong consistency is extremely difficult for a distributed system. That means that all members must collaborate to keep the service operational.
  • Operational complexity: You need a mature operations team to manage many services, which are re-implemented regularly.

Should I recommend microservices to my clients?

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.

Oriol Fernandez Moreno – Key Software Developer at Itequia