Why you can no longer ignore microservices as a CIO

19 August, 2022 / Alex Wilbrink

Microservices — Why do so many software companies choose this architecture?

We know Amazon as one of the largest webshops in the world. Yet a significant part of their revenue comes from operating so-called micro-services. The overwhelming amount of publications regarding this topic is convincing. An excited colleague started thinking about redesigning his core application with Amazon microservices. About two years later, he changed his mind. The micro-services architecture took much more time and, according to him, was certainly not an ideal choice for integrated Enterprise apps.

We show you what micro-services are, why you would choose this type of software architecture as a CIO, and see why the colleague in question concluded that microservices are not optimal for Enterprise Applications (ERP). Was he right?

 

What are microservices?

There are different architectures out there to build your business applications with, all of them with their own advantages and disadvantages. Microservice is an architecture choice, or better: a style. Although the definition has been altered by some, the core o microservices is that a large application is divided into smaller applications – multiple microservices. This combination of microservices has the same functionality as the original 'software monolith'.

 

Why microservices?

Arguments in publications about microservices, often based on Amazon experiences, sound appealing:

1. Better performance 

With a micro-services strategy, you divide monolithic software into smaller, individually complex parts, which contain necessary connections to other micro-services. This makes it easier to track performance issues and resolve them.

2. Better maintainable software
The individuality of microservices makes it easier to customize, and usually fewer bugs are introduced. This also means that software can be developed more quickly. That way, end-users experience the latest adjustments and new features faster.

3. Reusability
Reusing code is of strategic importance for software companies. And although other architecture styles also facilitate this, it is an appealing aspect of the microservices approach. The Lego blocks metaphor, where a product consists of various parts, can be designed in this way.

4. Develop in multiple languages
Microservices have their own codebase and "communicate" through standard protocols. This makes it possible for each microservice to be written in a different development language. An example from the manufacturing industry: the combination of MES functionality with IoT data can be tackled coherently with a microservices set-up. IoT requires a time-series database and a phyton-like interpretation logic – in addition to the more classic MES functionality.

5. A faster development speed
Besides the technical possibilities of microservices, this type of software architecture also offers focus within the development team. By concentrating on one or more specific microservices, the teams gain greater independence from each other, which speeds up the development.

 

Why wouldn’t you go for microservices?

The arguments mentioned above seem strong and proven. At the same time, the choice of the colleague mentioned above turns out to be less obvious in retrospect. This depends on the following conditions:

Yet again complex – prone to errors?
A problem with a microservices architecture can be that the many communicating microservices as a whole are much more complex than a non-microservices-based system. An Enterprise Application that consists of a combination of microservices, databases, logic, messaging, deployment, etc. based on different development languages ​​can also cause errors; this can negate the advantage of a well-arranged architecture. So the question is to what extent is this unbalanced for a microservices-oriented architecture? A delicate choice that you have to think about.

Development teams not ready yet?
In the case of our colleague we just mentioned, it turned out that the development team was not aware of the design principles of a microservices-based architecture. Lots of time was spent on tooling to overcome the disadvantages of micro-services, resulting in delays and insufficient delivery of the microservices. It requires a change in a developers’ mindset and therefore thorough preparations for the development teams.

 

Microservices versus the manufacturing industry

We now ask ourselves: does the use of micro-services make sense within business applications in the manufacturing industry? You would say so, since for many, ERP stands for complex, maintenance-sensitive, and no longer capable of innovation. 

After years of experience in the industry, the Togetr team knows the advantages of a microservices-oriented architecture and has largely neutralized the disadvantages. It is possible to provide coherence in an ERP system with a much simpler architecture. Depending on their need, customers can extend their system with microservices-based Togetr solutions. The sales department implements Togetr CRM, an assembly plant starts with the modern Togetr MES, perhaps combined with Togetr Planning and PLM; which are also available as standalone applications.

 

Our statements about micro-services

It is undeniable that large companies are successful with microservices. This approach is also important for business applications in the manufacturing industry. The increasing heterogeneous demands placed on technology make a microservices strategy inevitable.

The definition of the microservices boundaries follows the business case and provides a more flexible business system. Integrity and flexibility must be weighed together in a balanced way. The scope of a microservice needs to be chosen delicately with far-reaching consequences when it comes to complexity versus flexibility.

 

Microservices offer opportunities for both customers and development teams to develop and implement cohesive parts of the application.


We think that even the somewhat skeptical colleague will eventually use microservices in the future. What do you think? We are curious to hear your opinion about microservices!