Microsserviços é uma abordagem de desenvolvimento de software, na qual em vez de construir uma aplicação como grande monolito (que concentra todos os componentes em um único lugar), você divide os componentes em “micro” serviços, que são construídos de forma independente, autônoma e com baixo acoplamento.
Com uma visão um pouco mais técnica, apresentamos o conceito de arquitetura de microsserviços, de Martin Fowler e James Lewis, ambos consultores de tecnologia, reconhecidos no meio do desenvolvimento de software:
“O estilo arquitetural de microsserviço é uma abordagem para desenvolver uma aplicação como um conjunto de pequenos serviços, cada um executando em seu próprio processo e comunicando-se através de mecanismos leves. Esses serviços são construídos em torno dos recursos de negócios e implantáveis de forma independente totalmente automatizada. Há um mínimo de gerenciamento centralizado desses serviços, que podem ser escritos em diferentes linguagens de programação e podem usar diferentes tecnologias de armazenamento de dados.
— James Lewis e Martin Fowler, tradução livre
Esse conceito vem sendo discutido desde 2011, quando o nome “microsserviço” se consolidou como um estilo de arquitetura e desenvolvimento de software. E, apesar de ter se tornado, ainda em 2014 um termo “da moda”, seu uso ainda não está 100% estabelecido no mercado.
Pensando nisso, você confere nesse post as principais propriedades dos microsserviços, porque ele é uma excelente escolha para o desenvolvimento de software e a sua relação com o open banking. Confira:
Propriedades dos microsserviços
Apesar de não existirem regras e métricas exatas para conceituar os microsserviços, normalmente, eles são caracterizados levando em consideração 4 propriedades fundamentais: alta coesão, baixo acoplamento, autonomia e independência.
1.Alta coesão
“Agrupe as coisas que mudam pelas mesmas razões. Separe as coisas que mudam por razões diferentes”. Essa citação de Robert C. Martin (também conhecido como “Uncle Bob”), referência na comunidade de desenvolvimento de softwares, nos ajuda a entender melhor o conceito de coesão e como ele se relaciona com o princípio da responsabilidade única.
O grau de coesão de um componente de software indica o quanto as diferentes funcionalidades implementadas por ele estão relacionadas entre si e dizem respeito ao mesmo domínio de problema.
Nesse contexto uma classe (ou microsserviço) deve ter apenas uma única responsabilidade e realizá-la de maneira satisfatória. Dessa maneira, ele não mistura suas responsabilidades com a de outros componentes, não delega essa responsabilidade a outros microsserviços e nem busca resolver problemas que não estão associados exclusivamente a ela.
Caso esse princípio seja ignorado, você poderá ter dificuldades de manutenção e reuso do software, por exemplo.
2.Baixo Acoplamento
O grau de acoplamento de um componente de software diz respeito ao quanto ele está interligado ou relacionado a outros componentes. Em certo sentido, ele indica o quanto um determinado componente depende de outros dentro de um sistema. No caso dos microsserviços, é desejável que a relação de interdependência de seus componentes seja baixa (ou fraca).
Dessa forma, cada microsserviço terá um grau maior de independência, o que simplificará seu reaproveitamento. Essa característica também facilitará sua manutenção, uma vez que essa independência proporcionará um isolamento funcional que restringirá a exigência de propagar para outros componentes uma determinada alteração em seu funcionamento interno.
Portanto, podemos entender que acoplamento é uma medida “inter” componentes, referindo-se ao mundo externo do componente, e que coesão é uma medida “intra” componentes, que se refere ao modo com o qual os componentes se relacionam entre si.
3. Autonomia
Os microsserviços precisam ser autônomos, ou seja, totalmente capazes de gerenciar, orquestrar a comunicação e executar suas próprias tarefas sem depender de outros serviços externos.
Isso também vale para situações nas quais existe um fluxo de execução a ser seguido, com serviços encadeados.
4. Independência
Idealmente, um software componentizado deveria ser constituído apenas por componentes independentes, que funcionam totalmente a parte de qualquer outro recurso ou componente externo.
Na prática, isso é impossível ou bastante improvável, mas, é importante ter esse conceito em mente para evitar ou minimizar a criação dessas dependências externas (ou, pelo menos, ter uma boa justificativa para quando isso acontecer).
Como você pode perceber existe uma relação entre esses 4 conceitos. Por exemplo, baixo acoplamento praticamente implica em alta coesão. De maneira similar, para ter independência é necessário que os microsserviços sejam altamente coesos. Autonomia e independência são conceitos que também se complementam.
Até mesmo porque, os microsserviços não estão isolados numa aplicação. Em algum momento eles precisam ter o mínimo de comunicação e coordenação entre si para saber quando executar as tarefas.
É aí que entra a arquitetura de microsserviços, isto é, a forma com que um conjunto de microsserviços é aglutinado de maneira ordenada para oferecer as funcionalidades de uma aplicação completa de forma coerente.
Qual o tamanho dos microsserviços?
No livro “Building Microservices: Designing Fine-Grained Systems”, o autor Sam Newman indica que “um microsserviço deve ser pequeno o suficiente, mas não menor do que isso”. Portanto, não existe uma “regra de ouro” para definir o tamanho de um microsserviço ou mesmo o tamanho da equipe que deve ser responsável pela sua construção, evolução e manutenção.
Portanto, o importante mesmo é garantir que os microsserviços sejam compostos por suas propriedades fundamentais.
Arquitetura de microsserviços
A arquitetura de microsserviços apresenta 5 características fundamentais que estabelecem o modelo a ser utilizado para a construção de cada componente do sistema e sua coordenação para a formação de um todo coerente. São elas: autonomia, resiliência, transparência, automação e alinhamento.
1.Autonomia
Os microsserviços devem ser criados em torno de funcionalidades de negócio, de forma a minimizar a necessidade de comunicação com outros serviços ou recursos. A comunicação deve ser feita através de contratos bem definidos que não expõem os detalhes da implementação de cada microsserviço.
Além disso, deve ser possível implantar os microsserviços de forma independente do restante da aplicação, com liberdade com relação à tecnologia e linguagens utilizadas para implementar os microsserviços (incluindo os mecanismos de persistência de dados). As aplicações compostas de microsserviços devem ser capazes de lidar com essa multiplicidade de linguagens usadas para codificar cada microsserviço.
2. Resiliência
Separar a aplicação em vários microsserviços, permite que eles sejam implantados de forma independente, fazendo com que possíveis falhas sejam isoladas e afetem apenas pequenas partes da aplicação e não o sistema como um todo.
Dessa forma, em vez de ter apenas um ponto de falha, a aplicação passa a ter vários pontos que podem, eventualmente, apresentar algum problema. Por isso, mecanismos de monitoramento, detecção e recuperação de falhas precisam ser incorporados.
3. Transparência
Para que a característica da resiliência seja bem estabelecida, é fundamental que o sistema completo seja transparente e observável. Somente assim será possível identificar, diagnosticar e corrigir problemas e falhas.
Para isso, a principais ferramentas utilizadas são os logs da aplicação e o rastreamento de requisições realizadas.
4. Automação
A complexidade da arquitetura de um sistema composto de microsserviços é maior que a de um sistema monolítico. Existe, portanto, a necessidade de automatizar as atividades associadas a todas as etapas de disponibilização sistema:
- Build;
- Testes automatizados;
- Deploy.
Além disso, deve ser possível (e simples) atualizar apenas partes do sistema (microsserviços isolados).
A automatização de tarefas manuais eliminará erros, garantindo uma implantação correta e o funcionamento do sistema. Podemos notar então, uma relação muito forte entre a arquitetura de microsserviços e as técnicas de DevOps.
5. Alinhamento
É fundamental que a construção dos microsserviços seja baseada nos conceitos de negócio associados à aplicação. As funcionalidades necessárias devem ser adequadamente distribuídas entre os microsserviços, garantindo as propriedades de alta coesão, baixo acoplamento, autonomia e independência, que já citamos anteriormente.
Nesse quesito, a disciplina de DDD (Domain-Driven Design) é de grande utilidade. Idealmente, as equipes de desenvolvimento e implantação devem ser organizadas em torno dos microsserviços, com cada equipe sendo responsável por um ou mais componentes de maneira independente das outras.
Por que microsserviços?
Uma arquitetura de microsserviços, pode ser sim mais complexa, porém traz para o seu sistema escalabilidade, maior tolerância a falhas, além de facilitar os processos de atualização do sistema.
Tanto a escalabilidade quanto os processos de atualização constante do sistema estão relacionados a computação em nuvem, o que favorece a implementação do conceito de elasticidade dinâmica, já que os microsserviços permitem um ótimo ajuste da variação de recursos computacionais para se adequar à flutuação da demanda.
Ou seja, a facilidade oferecida pela computação em nuvem para alocar e liberar recursos computacionais (por exemplo, máquinas virtuais e contêineres) permite que as aplicações se ajustem à demanda. Afinal de contas, é mais comum que apenas determinadas funcionalidades da aplicação apresentem picos de utilização.
Por exemplo em uma aplicação de conta corrente a função de consulta ao saldo é bem mais demandada do que o pedido de um extrato detalhado dos últimos 6 meses. Assim, quando houver um pico de utilização, basta alocar mais recursos e disparar novas instâncias para o local específico. Quando o uso cair, é só liberar esses recursos.
No caso de aplicações construídas como monólitos, o disparo de novas instâncias exigirá que toda a aplicação (e todo o código referente às suas várias funcionalidades) seja replicada.
Assim, como você pode observar na imagem abaixo, os microsserviços trazem economia de recursos computacionais – e custo – por permitir um ajuste mais preciso entre a curva de demanda e o uso desses recursos.
Já se tornou uma exigência dos negócios digitais a realização de alterações constantes nas aplicações e elas podem ser das mais variadas: correção de erros, realização de testes A/B, lançamento de promoções ou mesmo ajustes de última hora.
Portanto, dado que a computação em nuvem, somada à automatização do processo de build e deploy, agiliza o processo de disponibilização de novas versões das aplicações em ambiente de produção, torna-se frustrante recompilar e executar exaustivos testes automatizados sobre aplicações muito grandes, o que atrasa o processo de colocar no ar uma nova versão de uma aplicação, especialmente se as alterações forem realizadas apenas em uma pequena parte do sistema. Os microsserviços permitem quebrar o problema, permitindo atualizar apenas as funcionalidades necessárias, sem precisar mexer no restante da aplicação.
Além disso, ao longo do tempo é mais difícil manter a estrutura de um monolito, especialmente no que tange à sua modularidade. A complexidade de manutenção de aplicações grandes faz com que a correção de uma determinada parte possa quebrar outras funcionalidades, o que vai apenas se tornando uma bola de neve, já que você vai precisar investir mais tempo na realização de alterações mínimas.
Um modelo distribuído proporciona uma maior tolerância a falhas, minimizando seu impacto. Isso porque em uma aplicação única, uma falha em uma determinada funcionalidade pode acarretar a indisponibilidade de todo o sistema. No modelo de microsserviços, uma falha em uma determinada funcionalidade não implica na parada das outras funcionalidades disponíveis.
Benefícios do uso de microsserviços
Se você estava procurando entender melhor como os microsserviços impactam positivamente no seu dia a dia, nós já te demos 3 bons indicativos no tópico anterior. Porém, não podemos deixar de ressaltar os 4 benefícios abaixo:
1. Heterogeneidade Tecnológica
Como os microsserviços tem baixo acoplamento, é possível adotar tecnologias específicas para cada trabalho. Por exemplo, se uma parte do sistema necessita de melhor performance, é possível atender essa demanda com as ferramentas específicas, sem a necessidade de adotá-las para todo o sistema.
Na mesma lógica, também podemos adotar novas tecnologias mais rapidamente e com menores riscos.
2. Facilidade de implantação
Por conta da possiblidade de fazer alterações em um serviço de forma independente, a implantação se torna muito mais simples e ágil. Isso permite que sejam disponibilizadas novas funcionalidades para os usuários com mais rapidez.
3. Capacidade de composição
Como os serviços são independentes e autônomos, é possível que eles sejam utilizados para compor outros sistemas. Dessa forma, as funcionalidades podem ser “emprestadas” para outros negócios totalmente diferentes do projeto original.
4. Substituição de código
Como os serviços são pequenos, esta arquitetura diminui o risco e o custo de substituição total da base de código.
Open Banking e microsserviços
O open banking, é uma iniciativa global, que tem como objetivo descentralizar informações financeiras, permitindo que os titulares de seus dados tenham autonomia para compartilhar seus dados e decidir como, onde e por quais instituições financeiras eles podem ser usados. No Brasil, definido como uma norma regulatória pelo Banco Central (BC), a implementação desse modelo está na primeira fase e a expectativa é que a quarte a última fase do projeto seja finalizada até dezembro de 2021.
O compartilhamento desses dados será realizado por meio de APIs abertas, que farão essa “ponte” entre as instituições financeiras, claro, mediante a autorização dos clientes.
Mas, como o open banking e os microsserviços se relacionam? A resposta é bem simples: a arquitetura de microsserviços é a melhor opção para a construção da API de open banking.
Isso porque as características de resiliência, associadas à possibilidade de automação oferecem uma solução ideal para atender às exigências de disponibilidade ininterrupta impostas pela regulação. O ideal é que a solução seja construída para suportar uma demanda crescente, alocando dinamicamente recursos computacionais (e seus custos correspondentes) apenas no nível necessário para atender as demandas.
Além disso, a tendência é que com o open banking, os serviços se tornem ainda mais categorizados. Isso porque, novos modelos de negócio e aplicativos podem surgir e é natural – e até mais vantajoso – que essas APIs sejam independentes, facilitando a atualização, manutenção, escalabilidade, evitando atrasos, lentidão e alteração no tempo de resposta, para respeitar as exigências do Banco Central.
Até mesmo porque, um dos objetivos do open banking Brasil é justamente tornar o mercado financeiro mais competitivo, ampliando as ofertas de serviço e melhorando a experiência do cliente. Ou seja, essa é também uma oportunidade de inovação e crescimento para muitas empresas do setor.
Pensando nisso, a Opus desenvolveu uma solução, a OPUS Open Banking, que é ideal para que você possa cumprir as regulamentações do Banco Central e usar a obrigatoriedade imposta pela regulação como um diferencial competitivo. Quer saber mais? Entre com contato com a gente!
