Quando nos tornamos experientes no ciclo de desenvolvimento de um software, é comum começarmos a trabalhar com sistemas distribuídos, utilizando as ferramentas corretas para cada contexto, até nos depararmos com os mais diversos formatos de comunicação.
O que devemos considerar?
Enquanto seguimos boas práticas de governança, também é comum deixarmos de lado alguns recursos que não seriam tão adequados para resolverem os nossos problemas em questão.
Nós utilizamos processos de integração contínua para verificar detalhes como a qualidade do código e a segurança. E, se tudo estiver em ordem, nós enviamos os nossos resultados para um ciclo de CD antes de iniciarmos o deploy do sistema. Entre as nossas responsabilidades nós também utilizamos ferramentas que nos ajudam a ter observabilidade, tanto no aspecto geral como individual.
Na observabilidade individual vemos o panorama do nosso sistema em si, as suas métricas, a performance, assim como os números de negócio e infraestrutura. E pela observabilidade geral nós verificamos se algum sistema externo não está afetando o nosso próprio sistema.
Há uma situação típica em que um sistema depende de um outro sistema que está lento. Para resolver isso e garantir resiliência, possibilitando a adição de um Circuit Breaker, por exemplo, devemos ter uma visão ampla de como trabalhamos com nosso próprio serviço.
Então perceba que apenas pelo fato de se trabalhar com um único microsserviço, por mais simples que ele pareça, existem diversos fatores que nós devemos considerar para lidar com esse único componente em meio a muitos outros.
Seja para fins de estudo ou com o objetivo de implementar essa abordagem arquitetônica numa empresa, os microsserviços são um ótimo começo para quem pretende ser um Full Cycle Developer.
Padrões de Microsserviços
Se você está no meio dessa trajetória de descobrir novos padrões, há um site chamado microservices.io onde você encontra uma grande variedade de padrões que normalmente são utilizados para a criação de softwares utilizando microsserviços. Clique aqui para acessá-lo.
Durante o seu aprendizado e prática você vai entender que existem diversos componentes, com as mais diversas finalidades, que vão melhorar todos os aspectos da sua infraestrutura de uma forma bastante eficiente e detalhada.
Entre os diversos padrões, que realmente são variados, você também vai perceber que muitas pessoas só procuram por isso quando têm necessidade. E não há porque fugir disso, já que em algum momento você vai ter que aprender.
No padrão Saga, por exemplo, ele permite que você realize transações e operações entre os seus microsserviços. E se algum deles falhar em alguma parte da transação, você pode desfazer a transação para os demais microsserviços.
Existem muitos padrões que nós não precisamos entender a fundo, principalmente pela variedade, e é muito difícil que um profissional explore todo esse conteúdo. O desafio de aprender tudo isso vai além de trabalhar no mesmo sistema e fazer os mesmos CRUDs todos os dias.
Mentalidade
Ser um desenvolvedor, principalmente um desenvolvedor Full Cycle, não é sobre utilizar padrões, modelos e criar várias telas de cadastro, por exemplo; vai muito além disso.
Obviamente ninguém aprende tudo de uma só vez; é uma jornada. Mas um dos principais objetivos da Full Cycle é sintetizar todo esse conhecimento no nosso idioma, considerando que esse tipo de conteúdo é voltado para um nicho muito seleto de desenvolvedores.
Entre todos esses aspectos, um desenvolvedor Full Cycle vai muito além de especialidade, mas de mentalidade. Pois, se você souber aonde você quer chegar, você vai chegar no seu objetivo, estudando e entendendo o contexto geral de como procurar pelas soluções que você precisa por conta própria e enfim atender às suas necessidades.
Se você curtiu esse post e está pronto para mergulhar no mundo dos microsserviços, solicite contato clicando aqui e nós te ajudamos.
