microsserviços

Micro Front-End – Microserviços no seu navegador

Olá Web Developers! Vamos entender o que é Micro Front-End. Já tivemos aqui no blog posts relacionados a Microsserviços e Micro-Frameworks, que eu recomendo a leitura para servir de base para o entendimento deste post.

Micro vs Monolítico

Quando dizemos que um sistema é monolítico, estamos nos referindo a monólitos (mono = um, lito = pedra). Uma referência a, por exemplo, montanhas que são formadas por uma única pedra, como é o caso do morro do Pão de Açúcar.

Nesse sentido estamos indicando que o sistema é grande e inflexível, pois normalmente se baseia em uma única estrutura, framework e padrão. Não estou dizendo que isso é ruim.

Já quando falamos em micro, estamos nos referindo a pequenas peças que se unem para formar algo maior, como blocos de montar.

Angular - Tópicos avançados
Curso de Angular - Tópicos avançados
CONHEÇA O CURSO

O que é Micro Front-End?

O mais comum hoje em dia é construir uma aplicação inteira com uma única biblioteca ou framework (normalmente React, Angular ou Vue). Em contraste com essa ideia, imagine uma aplicação que na verdade é feita de pequenas aplicações independentes que se integram.

Nesse sentido, poderíamos ter até mesmo uma mesma tela feita por frameworks diferentes. Um pedaço pode ter sido feito com Angular e outro com Vue. Loucura? Bagunça? Talvez não.

A ideia de Micro Front-Ends é exatamente permitir que cada pedaço da aplicação seja independente. Isso realmente não faz sentido nenhum para aplicações de pequeno e médio porte. Entretanto, aplicações de grande porte normalmente necessitam de algumas estratégias diferentes para que possam continuar crescendo sem afetar sua qualidade.

Tela de compra criada usando diferentes Frameworks com modelo de micro front-end

(No exemplo acima, a tela de exibição do produto é feita em Angular, a parte relacionada à compra é feita em React e a lista de produtos relacionados é em Vue)

Portanto, pense em projetos em que há pelo menos dois times diferentes trabalhando no Front-End de uma mesma aplicação. Um time pode ter um problema em que uma ferramenta X seria perfeita, mas que poderia dificultar as atividades do outro time, que prefere usar a ferramenta Y.

Se cada pedaço da aplicação for independente, cada time pode escolher suas tecnologias, métodos de trabalho, horários de reunião, casos de teste, momento para deploy, etc. Assim, cada um conseguirá ter um melhor aproveitamento. Se uma equipe precisa atualizar a sua parte, a outra não precisa ser envolvida e nem terá seu trabalho influenciado.

Além disso, e se algum módulo da aplicação tiver uma ferramenta obsoleta e precisa ser atualizada ou até mesmo trocada? Em uma aplicação comum teríamos que arrumar o código inteiro, o que é totalmente inviável para aplicações grandes. Você já deve ter ouvido o famoso “deixa assim ou refaz do zero”. Entretanto, se cada módulo da aplicação é independente, você pode mudar cada pedaço da aplicação aos poucos, sem influenciar no todo.

React - Despertando o Poder dos Hooks
Curso de React - Despertando o Poder dos Hooks
CONHEÇA O CURSO

Como os Micro Front-Ends se comunicam?

Ainda que a ideia é deixar cada pedaço da aplicação independente, as partes necessitam conversar e compartilhar certos dados. Um ótimo exemplo é ter um módulo de login e outro de compra de produtos. É necessário saber quem é o usuário logado para poder finalizar uma compra.

A fim de possibilitar a comunicação entre os pequenos pedaços da aplicação, podemos utilizar coisas como o próprio LocalStorage, por exemplo. Ou então criar eventos para possibilitar a comunicação.

Há ferramentas que ajudam a permitir essa integração. Uma delas é o https://single-spa.js.org/.

Também é importante deixar claro que ainda é importante que as equipes sigam certas regras e padrões. Do contrário, o sistema seria estranho, com botões diferentes em cada tela, animações em diferentes estilos, etc.

Aplicações monolíticas são coisas do passado? Devo mudar meu jeito de trabalhar e usar micro front-ends?

Jamais! Cada aplicação sempre deve ser estudada e planejada de acordo com as necessidades e problemas a serem resolvidos. Haverá casos em que micro front-ends apenas darão mais trabalho e dores de cabeça ao invés de melhorias. Por isso sempre é importante conhecer várias ferramentas e maneiras diferentes de trabalhar, pois só assim você saberá o que fazer e usar em cada momento.

Resumindo, os micro front-ends dão uma maior flexibilidade para aplicações de grande porte que possuem vários times. Mas não vão trazer vantagens para pequenos projetos em que há poucas pessoas envolvidas.

Vue.js - Criação de interfaces web
Curso de Vue.js - Criação de interfaces web
CONHEÇA O CURSO

O que é Circuit Breaker?

No artigo sobre microsserviços, vimos a quantidade de vantagens que ele possui, como o baixo acoplamento, reuso de código e a agilidade no desenvolvimento. Mas, como a ação dos usuários disparam diversos serviços separadamente, falhas nas chamadas das cadeias de serviço podem acontecer. Afinal, como lidar com momentos onde um ou mais serviços ficam indisponíveis? Confira neste artigo o Circuit Breaker.

O que é Circuit Breaker?

É um padrão de projeto que permite construir serviços que sejam tolerantes a falhas, permitindo que uma aplicação lide com eventuais indisponibilidades nos serviços adjacentes.
O termo Circuit Breaker em português significa “disjuntor elétrico”.

Este padrão prevê a implementação de uma estrutura que atue igual a um disjuntor elétrico, desarmando comportamentos de uma aplicação quando elementos envolvidos comecem a apresentar muitas falhas e/ou indisponibilidade.

Com sua utilização, é possível garantir um desempenho estável principalmente com relação às integrações entre microsserviços, onde podemos monitorar falhas e fornecer um serviço alternativo ou mensagem de erro mais acessível.

Estados

O Circuit Breaker tem 3 estados distintos:

Closed: este é o seu estado normal. Ele permanecerá fechado, ou seja, ele permitirá a passagem de fluxos de dados normalmente;

Open: neste estado, ele “abre” o circuito de comunicação entre estruturas (como outros microsserviços ou até mesmo outras estruturas dentro de um mesmo microsserviço). Assim como em um circuito elétrico aberto, onde a energia deixa de fluir, um microsserviço que fique com o circuit breaker aberto deixará de operar o fluxo que for afetado por ele, passando a retornar uma mensagem de erro ou mesmo passando a executar fluxos de emergência;

Half-Open: depois de um período com o circuito aberto, seu estado pode ser alternado para half-open. Isso ocorre como um mecanismo de recuperação, pois enquanto o circuit breaker está neste estado, o próprio avaliará se o fluxo ainda continua em estado de falha ou se já foi reestabelecido através de uma sequência de verificações. Se uma única chamada falhar nesse estado semi-aberto, o circuit breaker abrirá novamente. Caso as chamadas voltem a ser feitas com sucesso, o circuit breaker irá fechar o circuito novamente, retornando ao estado normal.

Considerações finais…

Este padrão pode nos ajudar muito em problemas associados à disponibilidade e capacidade de resposta ao se comunicar remotamente com microsserviços. Isso certamente irá aumentar significativamente o desempenho e a capacidade de resposta em seu aplicativo de microsserviços (ou qualquer outro tipo de aplicação principalmente remoto).

O que são microsserviços?

O termo “microsserviços” tem sido muito utilizado nos últimos anos. Confira neste artigo o que é um microsserviço e quando utilizá-lo.

Afinal, o que vem a ser os microsserviços?

Microsserviços são uma abordagem de arquitetura para a criação de aplicações, onde cada pedaço dessa aplicação é desenvolvido e disponibilizado de forma independente. Cada processo da aplicação é executado como um serviço.

Quando falamos em microsserviços, estamos nos referindo a uma funcionalidade que pode ser dividida em partes menores. Desse modo, essas pequenas partes se comunicam por meio de uma interface bem definida usando APIs. Em outras palavras, como são executados de forma independente, cada serviço pode ser atualizado e implantado para atender às demandas de uma aplicação.

Uma arquitetura de microsserviços é um estilo moderno de arquitetura para web services, o que nos remete a outra arquitetura: a SOA. A SOA é uma alternativa à abordagem tradicional de construção de aplicações autossuficientes, as quais chamamos de monolíticos.

Se forem construídos corretamente, os serviços independentes não afetarão uns aos outros, ou seja: se um deles falhar, o restante da aplicação permanecerá em funcionamento, ao contrário do modelo monolítico.

O que são aplicações monolíticas e quais os problemas?

Ao contrário dos microsserviços, as aplicações monolíticas tem todas suas funcionalidades em um único processo, fazendo com que tenha um grande conjunto de funcionalidades em uma única estrutura, gerando alto acoplamento e indisponibilidade de toda a aplicação caso haja alterações ou implantação, mesmo que haja apenas um único ponto de falha.

Ainda assim, ele é interessante para aplicações pequenas, mas caso você esteja trabalhando com uma aplicação um pouco maior, alguns problemas podem surgir.

Quais são os benefícios da arquitetura de microsserviços?

A utilização de microsserviços pode trazer muita produtividade, pois você pode desenvolver vários microsserviços ao mesmo tempo, com diversos desenvolvedores trabalhando de forma simultânea na mesma aplicação com abordagens diferentes (como tecnologias envolvidas). Nesse sentido, temos nossas equipes bem focadas em suas tarefas, resultando em mais produtividade em menos tempo e um trabalho mais eficiente.

Flask - Fundamentos
Curso de Flask - Fundamentos
CONHEÇA O CURSO

Vantagens e desvantagens de se utilizar microsserviços

Vantagens
  • agilidade: com os deploys e testes independentes, temos uma maior agilidade no desenvolvimento e na implantação;
  • baixo acoplamento: com as aplicações são independentes, elas não possuem um acoplamento forte entre si. Isso facilita processos de manutenção, implantação e monitoramento;
  • escalabilidade flexível: cada serviço e funcionalidade pode ser escalado de maneira mais adequada e granular. Com isso, é possível obter até mesmo economia na manutenção da infraestrutura, pois o hardware pode ser escalado de maneira mais efetiva;
  • flexibilidade para implantação de tecnologias heterogêneas: como não existe acoplamento explícito e cada serviço é independente, podemos ter diferentes serviços escritos em diferentes tecnologias comunicando-se entre si. Isso permite utilizar linguagens mais adequadas para diferentes situações.
Desvantagens:
  • Complexidade na implementação e operação de sistemas distribuídos: sistemas distribuídos trazem complexidades adicionais, como monitoramento, consistência e distribuição de transações, pulverização de fontes de dados etc.;
  • Testes: testar uma aplicação com muitas dependências de serviços pode ser desafiador.

Quando deve-se considerar utilizar essa abordagem?

É preciso entender quando e como usar corretamente uma arquitetura orientada a microserviços. Pontos como complexidade do negócio, tamanho da equipe e distribuição das atividades são pontos relevantes a serem considerados. Caso contrário, a chance da adoção de uma arquitetura orientada a microserviços fracassar cresce consideravelmente.

Por isso, alguns casos que devem ser levado em conta ao utilizar a abordagem de microsserviços é em aplicações grandes e complexas. Essas aplicações geralmente precisam de uma alta taxa de velocidade de liberação, além de precisarem ser altamente escaláveis e disponíveis.

Considerações finais…

Os microsserviços são parte importante da estratégia de desenvolvimento de projetos distribuídos e altamente escaláveis. A utilização de microsserviços facilitam a escalabilidade e na agilidade do desenvolvimento, acelerando o tempo de introdução de novos recursos.

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200