Istio — Parte 1 — Introdução simplificando a arquitetura de microserviços

Criando uma malha de serviços de rede

Tenho estudado sobre alternativas ao NetFlix OSS. Desde a popularização junto ao Spring Cloud Netflix olho para aquelas annotations e penso que é “Cross cutting concern”, termo mais popular na Orientação a Aspecto.

Log, segurança e Transação são exemplos de responsabilidades cruzadas ao requisito de negócio

Cross Concern, basicamente é uma responsabilidade que cruza ou corta no meio o seu código de negócio. Por exemplo, toda vez que você olha para um código, que deveria ter apenas código de negócio, e encontra uma linha de log, esta linha é um “Cross concern”. Segurança, transação, caching, pooling, tratamento de exceções são outros exemplos típicos que encontramos na literatura.

Quando vejo “annotations” que habilitam funcionalidades do Netflix OSS, penso que elas não deveriam estar ali, sempre imaginei que alguns dos problemas que ele resolve, não deveriam estar em minha aplicação, coisas como circuit breaker, retries, load balancing, discovery, metrics, tracing, service discovery, canary release, rate limit, access control, A/B Test, fail injection (delay, aborts). Meu sentimento era de que estas coisas estão mais próximas da camada de rede, do que da camada de aplicação. Veja abaixo, uma imagem que ilustra como estas características engordam e tornam uma aplicação mais complexa, compare com a imagem a seguir e veja como é mais enxuta.

Aplicação antes do Istio

Com a preocupação de retirar do código de aplicação estas responsabilidades, comecei meus estudos a busca de alternativas. Eis, que encontro o conceito de Service Mesh, que me levou ao conceito de proxy de rede, Envoy, Linkerd, Kubernets, Istio, Jaegger e muitas outras ferramentas e conceitos interessantes. Veja abaixo, uma imagem que ilustra, como esta stack de tecnologias pode tornar sua aplicação mais leve, compare com a imagem acima. Oque nos leva a uma série de textos que vou compartilhar aqui no blog código refinado.

Aplicação depois do istio

Começo com algumas traduções, que pode não ser a perfeita, por isto sinta-se a vontade de marcar e sugerir a tradução melhor, também estou acrescentando informações a fim de enrriquecer sua leitura e meu aprendizado :). Hoje, dispobilizo a primeira delas e você pode encontrar o original nos endereços de referência.

Introdução ao Istio

Istio é uma implementação de “sidecar container” com funcionalidades necessárias para criar e gerenciar microserviços. Monitoring, tracing, circuit breaker, routing, load balacing, fault injection, retries, timeout, mirroring, access control, rate limiting , canary deployment, etc, são parte disto. Todas estas características, estão disponíveis usando um conjunto de bibliotecas (Netflix OSS) dentro do seu código. Oque distingue o Istio disto, é que você obtem estes recursos (benefícios) sem alterar seu código fonte.

Características do Istio X Kubernets

Utilizando o modelo sidecar, Istio é executado em um contêiner Linux, em pods Kubernets (parecido com um sidecar de uma motocicleta), injeta e extrai funcionalidades e informações. Isto quer dizer que ao utilizar o modelo de “sidecar container” você irá remover código e complexidade de sua aplicação, deixando-a mais leve ;)

O Service Mesh

Istio move aspectos operacionais para longe do código da aplicação. Ele roda fora do código fonte de sua aplicação. Service mesh, coordena um ou mais binários que cria uma malha de funções de rede.

A malha de serviços de rede está aumentando a medida que se torna mais popular, em termos práticos, estou dizendo que o ecossistema está crescento, logo, teremos tantos serviços de rede disponíveis que precisaremos de um diagrama para mapear e categorizar oque cada um faz.

Visão rápida

Uma vez que você inicia uma instância Minishift, você cria um projeto do Istio, vamos chamar isto de “istio-system”, e você instala e inicia todos os componentes relacionados ao Istio.

Uma vez que você está no ponto em que consegue levantar uma aplicação seguindo o desenho acima, quaquer das caraterísticas do Istio podem ser configuradas sem nunca tocar no código da aplicação.

Por exemplo, digamos que você quer direcionar o trafego de usuários de uma grande empresa para a nova versão de sua aplicação multitenant. Você pode fazer isto simplemente criando uma Istio Route Rule que pesquise por pelo dominio ou algo como @foocorporation.com no id do usuário e direcioná-lo adequadamente. Para o resto do mundo, isto é transparente, sendo direcionados a versão antiga, enquanto você testa e desenvolve seu novo software. Isto não exige nenhum desenvolvimento para que este direcionamento de trafego aconteça.

Istio é computacionamente custoso?

Não. É muito rápido, é escrito em GO, e adiciona sim um pequeno overhead em seu sistema. Além disso, o que você pode perder em desempenho on-line deve ser pago pela maior eficiência e velocidade do desenvolvendo funcionalidades de negócio, ao menos em teoria.

Existe uma série de textos que falam sobre os principais desperdícios no desenvolvimento de software. Um deles, é que o desenvolvedor precisa mentalmente trocar seu raciocionio de contexto (Task switch). Com Service Mesh na sua arquitetura de microserviços, tiramos parte deste desperdício por tirar do desenvolvedor algumas preocupações e análises.

Istio é apenas para Java?

Não. Aplicações escritas em outras linguagens podem se beneficiar dele. Veja abaixo uma imagem que ilustra este ponto, monstrando que aplicações escritas com outras linguagens se benefeciariam de Service Mesh.

No caso de Java, isto quer dizer que você remove um peso de sua aplicação deste tamanho:

https://www.slideshare.net/ceposta/atlanta-microservices-day-istio-service-mesh

Ou, se você utiliza Spring Cloud Netflix, você remove um peso deste tamanho:

Ou ainda, se você utiliza Vert.x

Acho que ficou claro, que ao adotar Service Mesh você irá remover um peso de sua aplicação, certo? :)

Outras partes desta série:

Parte 1 — Introdução simplificando a arquitetura de microserviços
Parte 2 — Route Rules: Dizendo a requisição para onde ir
Parte 3 — Circuit Breaker — Como lidar com ejeção
Parte 4 — Circuit Breaker: Quando falha é uma opção
Parte 5 — Tracing & Monitoring: Onde você está e quão rápido você está indo?Parte 6 — Engenharia do caos
Parte 7 — Lançamento negro — Serviços secretos
Parte 8 — Canary — Facilitando a produção
Parte 9 — Egress

Recomendações de leitura

https://amzn.to/2wcRHYx
https://amzn.to/2BFnWF3

Referência:

https://istio.io/
https://www.envoyproxy.io/
https://www.youtube.com/watch?v=6RKDz19LkLc
https://developers.redhat.com/blog/2018/03/06/introduction-istio-makes-
mesh-things/

https://developers.redhat.com/topics/service-mesh/
http://philcalcado.com/2017/08/03/pattern_service_mesh.html
https://www.slideshare.net/arnabmitra/service-mesh
https://learn.openshift.com/
https://www.slideshare.net/ceposta/atlanta-microservices-day-istio-service-

https://grafana.com/
https://prometheus.io/
https://www.jaegertracing.io/
https://www.kiali.io/
https://www.slideshare.net/tdc-globalcode/tdc2018sp-trilha-microservices-kiali-microservices-como-voce-nunca-viu-antes

https://www.infoq.com/minibooks/service-mesh-cloud-native-comms

codigorefinado

Código refinado

Clayton K. N. Passos

Written by

https://www.linkedin.com/in/claytonpassos

codigorefinado

Código refinado

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade