-
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 eu posso 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 observabilidade boa 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 Circuito Breaker,
que vai simplesmente limitar
-
o uso e o acesso a algumas fichas
para que eu evite de desmoronar
-
toda a minha aplicação
por um acesso de carga.
-
A gente vai ter também o Fall Back,
-
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
-
num 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 eu nunca vou de apoiar
-
todos os meus microsserviços
de uma vez
-
na prática, a ideia é que soltei
um carrinho de compras, por exemplo.
-
Eu não vou ter só um microserviço
desse, eu vou ter 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.
-
Isso é um exemplo
de como eu consigo obter
-
o Zir ou o downtime deployment,
ou seja,
-
de apoiar 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 microserviç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 Frey Mocks.
-
Afinal de contas, são eles
que ajudam também nesse processo.
-
Em Java a gente vai ter um nome de
quando a gente fala de Python,
-
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 REST fruto
-
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 transar
somando dados em uma estrutura
-
que também é pública,
como por exemplo o Jeison
-
e permitindo que eu trate
toda a parte de segurança,
-
resiliência, teste, observo,
habilidade, 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 a 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 vai ser reaproveitada
-
e o seu uso 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.
