-
A construção de uma aplicação,
-
principalmente a que envolve o uso
de APIs,
-
passa por entendermos diversos pilares
que a gente tem que endereçar
-
para que toda aplicação de fato
opere como a gente pretende.
-
Um desses exemplos
é quando a gente começa a pensar
-
em uma arquitetura de microsserviços.
-
Eu não posso simplesmente
deixá-la rodando.
-
Eu preciso saber, por exemplo,
como que eu vou quebrar
-
esses serviços dentro das estruturas.
-
E aí a gente chama isso
de desacoplamento,
-
que é basicamente a ideia
-
de sairmos quebrando serviços
em partes menores.
-
Isso pode ser feito, por exemplo,
por domínio,
-
pela própria aplicação,
pela lógica de negócios.
-
A gente tem algumas alternativas
que podemos utilizar para isso.
-
As duas alternativas principais
é justamente a gente pensar
-
na quebra por domínios e subdomínios
e na quebra por negócios.
-
Essas serão as formas
mais corriqueiras da gente quebrar.
-
Mas vejam que isso
é só um dos pilares.
-
Na prática, a gente ainda vai falar
de muito mais coisa.
-
Um desses exemplos
é quando a gente fala da integração
-
dessas aplicações.
-
Por mais que eu esteja falando
em API,
-
eu tenho APIs distintas.
-
Em muitos casos,
a gente estará falando
-
até de tecnologias mesmo distintas,
-
o que é o grande barato
do uso de uma API.
-
E justamente aqui,
-
a gente vai ter que entender
algumas coisas.
-
Se eu utilizo soluções
proprietárias de API Gateway,
-
elas já terão as suas próprias
estruturas de comunicação.
-
Esse é o caso, por exemplo,
das soluções como a da IBM,
-
ou mesmo da WS,
que já trazem ali
-
uma padronização de APIs
para a gente utilizar.
-
Esses caras ainda podem ser seguidos
dos seus agregadores de mensagem
-
ou mesmo de diversos outros recursos
para que eu transforme um MEXE,
-
ou seja,
uma colmeia de serviços
-
em entre aspas,
uma estrutura unificada.
-
É através desse MEXE,
-
que vários serviços vão poder
se comunicar e interagir,
-
para que a gente entregue
tudo como sendo uma solução só.
-
A gente também pode falar dos pilares
ligados aos bancos de dados,
-
principalmente quando a gente pensa
que esses dados,
-
eles vão estar internalizados
dentro de cada um dos serviços
-
e que eu preciso ter toda uma estrutura
para tratá-los.
-
Dessa forma,
a gente vai sempre pensar
-
em como que eu vou
compartimentalizar esses dados,
-
como vamos fazer
as nossas requisições.
-
E aí aqui a gente terá o CQRS,
-
que é basicamente
uma estrutura de queries
-
que a gente vai conseguir utilizar
-
para conseguir chegar
dentro do nosso dado.
-
Vejam que só no pilar de dados,
a gente já estará falando
-
de uma infinidade de alternativas
e montagens que a gente consegue ter.
-
Além disso, a gente ainda terá
que falar de observabilidade.
-
Eu preciso saber se esse serviço
é íntegro,
-
como ele está operando,
-
se ele está consumindo
mais recursos do que deveria
-
e por aí vai.
-
A gente normalmente trata
nesses três caras do MLT,
-
"métricas, logs e traces".
-
Ou seja,
como eu entendo a aplicação,
-
como ela está respondendo,
quais mensagens ela está gerando
-
para que a gente consiga, de fato,
ter uma boa observabilidade dela.
-
E é justamente aqui que a gente
começa a falar
-
do pilar de testabilidade.
-
Como é que eu vou garantir
que tudo o que acontece
-
de fato está testado e validado?
-
Notem aqui que um pilar pode sempre
complementar o outro.
-
Se a gente fala de observabilidade,
-
onde eu quero ver o que está
acontecendo com a aplicação,
-
ela, de certa forma,
vai depender dos testes
-
para que a gente tenha ali
uma massa de informações,
-
que me permita entender melhor
o comportamento dessa aplicação.
-
É justamente aqui que a gente
vai começar a falar também
-
de outros tópicos que são transversais
a todos esses pilares.
-
Não adianta de nada
colocar uma aplicação para operar
-
que vai cair ao menor suspiro.
-
Justamente por isso,
-
a gente checa sempre técnicas
de resiliência,
-
como é o caso do Circuit Breaker,
que vai simplesmente
-
limitar o uso e o acesso
à algumas features
-
para que eu evite desmoronar
toda a minha aplicação
-
por um acesso de carga.
-
A gente vai ter também o Fallback,
-
que é basicamente a ideia
do que eu faço e para onde eu vou
-
caso um serviço caia.
-
E aí eu posso levar esse serviço,
de repente,
-
para uma versão antiga dele
em um servidor legado
-
ou vou usar outro serviço
alternativo,
-
mas eu sempre vou ter
que procurar uma alternativa.
-
Além disso,
a gente ainda possui a ideia
-
de eu trabalhar
com Blue-Green ou Canary,
-
quando a gente fala do nosso deploy.
-
A ideia que nunca vou deployar todos
os meus microsserviços de uma vez.
-
Na prática, a ideia é que se eu tenho
um carrinho de compras, por exemplo,
-
eu não vou ter
só um microserviço desse,
-
terei vários e eu mando parcelas
de acesso para cada um deles.
-
Dessa forma, quando eu preciso
fazer uma atualização,
-
se eu tenho, por exemplo,
quatro carrinhos de compra,
-
eu vou atualizar primeiro
uma parte deles,
-
depois a outra parte,
gerando o Blue e o Green.
-
Esse é um exemplo
de como eu consigo obter
-
o Zero Downtime Deployment,
ou seja,
-
deployar uma aplicação
sem nunca deixá-la fora do ar.
-
E, além disso,
-
a gente ainda tem que falar
dos métodos de Discovery,
-
da construção das interfaces gráficas.
-
Vejam que são vários pilares
que a gente vai discutir que uma API
-
tem que prover apenas para a gente
falar de um mísero microsserviço.
-
Foi justamente por isso que a gente
começou a caçar alternativas
-
para começar a simplificar
a construção das nossas APIs.
-
Um dos grandes aliados aqui,
foi a gente recorrer ao Restful,
-
uma API que implementa boa parte
dessa estrutura de forma automática
-
e que já traz consigo
uma linguagem padronizada.
-
Quando a gente pensa dessa forma,
a gente termina construindo algo novo.
-
É justamente aqui que a gente
começa a reparar
-
que quando eu falo de Restful,
-
eu vou estar falando não só do meio
de comunicação,
-
mas da construção.
-
E aqui a gente trata também
de como a gente vê os frameworks.
-
Afinal de contas,
-
são eles que ajudam também
nesse processo.
-
Em Java,
a gente vai ter o Node.
-
Quando a gente fala de Python,
eu vou ter o Flask.
-
Esses caras vão trazer a estrutura
dessa minha API
-
pré-moldada com boa parte
desses pilares já pré-implementados.
-
De quebra,
quando eu falo de Restful,
-
estou utilizando o HTTP,
-
que é uma linguagem padronizada
na internet desde os anos 90,
-
então a gente começa
a construir a API com uma linguagem
-
que todo mundo conhece,
transacionando dados
-
em uma estrutura
que também é pública,
-
como, por exemplo,
o JSON,
-
e permitindo que eu trate
toda a parte de segurança,
-
resiliência, teste, observabilidade,
divisão de domínios,
-
utilizando um framework
que já é de mercado.
-
É justamente aqui,
-
que a gente começa a ganhar
tempo.
-
Se antes a gente dizia que quando
eu trabalho com microsserviços,
-
uma arquitetura
orientada à microsserviços,
-
ela vai ser custosa
de começar a implementar.
-
Agora, de fato,
vou ter um gasto de aprendizado
-
dessa nova tecnologia,
mas muita coisa será reaproveitada
-
e o reuso vai terminar
sendo o carro-chefe
-
de tudo o que a gente vai trabalhar
na utilização de APIs
-
e principalmente,
em como ela consegue utilizar
-
os microsserviços para se potencializar.
