I still remember when I arrived in my first IT department, in a well-known ceramics company. They had just implemented BAAN, if ever those gigantic ERPs had just been implemented. It testifies that the chief consultant stayed on the company's staff, to adjust the system, they said. Almost 20 years later, nothing is the same.
Those large applications were monolithic, designed for predictable scalability, had a powerful relational database, with synchronised processing, and on local racks. They were updated occasionally, I could spend an entire night on it because, each time they updated, there was a large volume of improvements, and the administration was mostly manual.
The appearance of the cloud has changed everything.. The applications are broken down into smaller, decentralised services. These services communicate through APIs or through the use of events or asynchronous messaging. Applications scale elastically, horizontally, adding new instances as required. Different storage technologies are combined and processing is asynchronous. Updates are frequent and administration automated.
And that implies the making of many decisions.
Y eso lleva implícitas la toma de muchas decisiones. The three basic decisions have to do with:
Having a strategic partner with Cuatroochenta's experience to guide us in this field is an added value for both management and IT departments, as it will determine many aspects of the design of subsequent applications.
Another decision to make when we make the leap to the cloud is the style of architecture with which we are going to implement our application. And if there is a style that has become particularly popular, it is that of microservices. In this architecture, an application is made up of many small and independent distributed services, each of which provides a solution to a specific functionality. All these standalone functionalities are flexibly integrated via an API.
However, there are certain challenges to be addressed because, although it is true that each service is much simpler and more flexible in terms of development, all of them must be integrated harmoniously, taking into account that this architecture allows different teams working with different languages, different databases for each service, and different philosophies. That is why it is convenient to define standards for the entire project without compromising the flexibility provided by this architecture.
Without a doubt, having a consolidated DevOps culture will help the end user to benefit from an efficient application. A bad development can generate problems in the integrity of the data (which can be independent in each service), or a latency that is too high due to an excessive chain of dependency of the service (one service calls another and so on, so that congestion may occur if the design is not optimal). It must also be taken into account, in terms of dependency on services, that updating one should not influence the functionality of the rest, so version control is a very important aspect.
The agility that this architecture allows makes the administration of services one of its strengths, from updating a service to adding new features, with scalability being another strength. At Cuatroochenta, we use Kubernetes as an orchestrator to package a higher density of services per host, thus increasing efficiency in the use of resources.
With this philosophy, at Cuatroochenta we have developed applications such as the Butech Calculator, for the Porcelanosa Group subsidiary of the same name, an app that allows us to determine the amount of ceramic materials necessary for the development of architecture projects. We have also participated in the development of the digital transformation of a well-known civil works construction company, for which we have developed a web application capable of effectively managing all documentation regarding the subcontractors with which it works.
For us, the most important thing is that each part of the company does its work as if it were a microservice at the service of the whole:
