When I joined Grupo RUA in 2020, tasked with managing the Technology department, the first thing we did was conduct an analysis of the overall state of technology areas within the company at all levels. The intention was to understand all the opportunities for improvement and the risks we needed to address first.
One noteworthy aspect in such an analysis is the intrinsic need for active participation from employees who, after all, are the ones experiencing the value delivery from the IT areas on a daily basis. Additionally, we considered the cost and difficulty that technical debt imposes on the development team.
One of the main challenges we encountered for one of our flagship products, which we intended to internationalize and scale, was the need to decouple or break down all the business logic from a monolithic API (a single code repository with all responsibilities centralized) into a microservices architecture, where each microservice would be aware of and responsible for a small part of the business. In other words, a specific microservice for authentication (SignUp, SignIn, logins, etc.), another for content management (photos, banners, etc.), another for discount coupon logic, and so on.
The way these components function typically involves “orchestration” from a specific component (like an API) that makes requests to different microservices.
The goal of this architecture is to have “small” components interacting with each other and/or with other components, each autonomous and specialized in executing its own processes related to a specific problem, service, or functionality, while still being within the overall business logic. This makes it easier to maintain, with several virtues:
- Independent Scaling: Each microservice can be maintained and improved independently of the rest of the product, minimizing risks during deployments.
- Elasticity: It’s relatively easy to deploy additional instances of these microservices during demand spikes.
- Development Agility: Small improvements and value additions can be incorporated in bounded time iterations.
- Technological Independence: While each microservice interacts with other components, they can use different stacks or languages according to their specific characteristics. Some may require more robust technologies than others, different databases, etc.
- Code Reusability: Logics are reused, avoiding rewriting the same code multiple times. For example, an authentication microservice responsible for all registrations and logins.
- Deployment and Continuous Delivery: Deployment times are much shorter, and errors can be quickly reverted, allowing for quick rollbacks, aiding in experimentation and learning.
This is something Grupo RUA progressed on, and we will continue working on it whenever a business unit requires new functionality or improvements to the current logic.
It’s important to clarify that not everything is perfect in this architecture; it comes with its challenges:
- Increased system complexity as it decouples.
- Requires additional effort for monitoring and error management.
- Demands more resources: Physical or virtual hardware (cloud or hybrid/cloud).
- Requires defining new roles like DevOps, responsible for provisioning, deployment, and continuous release, which become indispensable.
- Implementation of new philosophies and work methodologies.
In conclusion, to achieve the goal of a scalable and international product that can respond to changes, is sustainable, and can grow agilely, the entire company must undergo changes and face significant challenges. We must step out of our comfort zone, learn new methodologies and technologies, adjust workflows, and redefine roles and responsibilities.
From my perspective, the effort is worth it, as it enables what technology and business enthusiasts seek: the creation of high-performance structures and teams that, with technology as an ally, generate impact on the business and customers (internal or external) with added value in the short term.
