Construção de uma plataforma de e-commerce: uma abordagem baseada numa arquitetura de microsserviços

Abstract

As arquiteturas monolíticas estão, em grande parte, presentes na maioria das plataformas de e-commerce, o que leva a um processo de modificação mais complicado e entregas demoradas ao cliente, uma vez que não está preparada para trabalho em paralelo. A arquitetura de microsserviços veio proporcionar outra forma de desenvolvimento destas plataformas, permitindo o trabalho em simultâneo por diferentes equipas, produzindo novas entregas para o cliente de forma mais acelerada e segura. Todavia, esta possui alguns desafios e complexidades, o que leva muitas vezes à escolha de uma arquitetura monolítica para o desenvolvimento da aplicação. A maioria das aplicações não são imutáveis, pois mesmo estando entregues ao cliente são sujeitas a modificações. Esta necessidade de modificar a aplicação leva a preocupações acerca da rapidez com que as novas funcionalidades são entregues ao cliente. É preciso tomar decisões no início do desenvolvimento sobre que arquitetura seguir, de modo a tomar a decisão mais vantajosa. No caso de aplicações monolíticas a mudança para uma arquitetura de microsserviços facilita este aspeto, bem como muitos outros. Contudo, esta separação pode-se tornar quase impossível se o monolítico não for bem preparado para uma eventual futura mudança. Uma das maiores dificuldades numa migração de um monolítico para microsserviços, relaciona-se com a definição do que deve ser cada microsserviço e na comunicação entre estes. A migração deve partir da identificação de partes do código que possam ser isoladas sem ter muito impacto no resto do código. Com o desenho de um diagrama de packages é possível obter uma visão sobre a estrutura do sistema, percebendo que componentes são mais fáceis e mais difíceis de extrair. Deve-se começar por extrair aqueles que contém menos dependências, adquirindo as vantagens de uma migração incremental que permite que sejam reduzidos os erros efetuados, porém, pode haver situações em que se queira extrair um componente com mais dependências. É necessário compreender o porquê da migração para uma arquitetura de microsserviços. Esta decisão não deve ser tomada apenas porque a arquitetura de microsserviços está em voga, mas sim por razões fundamentadas. Dentro destas razões encontra-se a rapidez com que as mudanças são efetuadas e colocadas em produção, pois é mais fácil realizar modificações e voltar a instalar os microsserviços sem que toda a aplicação tenha que reiniciar. Isto permite uma melhor estruturação da equipa, possibilitando que várias equipas possam trabalhar em simultâneo para a mesma aplicação, não prejudicando em nada outros microsserviço. Outra razão é a necessidade de escalar os microsserviços independentemente, providenciando maior robustez, pois a falha de um serviço não leva à falha de toda a aplicação ou então pela escolha de tecnologia, podendo-se implementar os microsserviço com a tecnologia que seja mais adequada e eficiente.

Monolithic architectures are largely present in most e-commerce platforms, which leads to a more complicated modification process and time-consuming deliveries to the customer as it is not prepared for work in parallel. Microservices architecture has provided another way of developing these platforms, allowing different teams to work simultaneously, producing new deliveries for the client in a faster and safer way. However, this has some challenges and complexities, which often leads to the adoption of a monolithic architecture for the development of the application. Most applications are not immutable, as they are subject to modification even when delivered to the client. This need to modify the application leads to concerns about how quickly new functionality is delivered to the customer. It is necessary to make decisions at the beginning of the development about what type of architecture to choose, in order to make the most advantageous decision. In the case of monolithic applications switching to a microservices architecture facilitates this aspect, as well as many others. However, this separation can become almost impossible if the monolith is not well prepared for possible future change. One of the greatest difficulties in a migration from a monolithic to microservices is related to the definition of what each microservice should be and the change of communication between them. With this, the migration should start from the identification of parts of the code that can be isolated without having much impact on the rest of the code. By drawing a package diagram it is possible to gain insight into the structure of the system, realising which components are easier and more difficult to extract. You should start by extracting those modules which contain fewer dependencies, acquiring the advantages of an incremental migration that allows the reduction of errors made and their size, however, there may be situations in which you want to extract a component with more dependencies. It is necessary to understand why migration to a microservices architecture is necessary. This decision should not be made just because microservices architecture is in vogue, but for well-founded reasons. One of these reasons is the speed with which changes are made and put into production, as it is easier to make modifications and reinstall the microservices without having to restart the whole application. This allows a better structuring of the team, enabling several teams to work simultaneously for the same application, without harming other microservices. Another reason is the need to scale microservices independently, providing greater robustness, as the failure of one microservice does not lead to the failure of the whole application, or by the choice of technology, being able to implement microservices with the technology that is most appropriate and efficient.