development, devops, howto, sysadmin

howto #3 – O que é, o que faz, do que se alimenta o Consul.io

fabio / 29 de novembro de 2016

Aviso: esse post não contem detalhes sobre o Consul, ele tenta colocar esse tipo de ferramenta em um contexto histórico, justificando sua existência e utilização bem como ser um repositório com links para sites que já possuem boa referência sobre o assunto e também para locais onde se possa aprender na prática sobre o serviço.


Microservices. Pronto, agora que o Google indexou essa página com a palavra mágica da moda eu posso começar a falar sobre o Consul.io 😉 Na verdade eu não associo o Consul.io necessariamente a microservices e vou explicar o porquê depois de falar sobre service registry.

Mas primeiro um pouco de história àqueles de vinte e poucos anos

#begin TLDR;

Pensando em tecnologia de forma abstrata, integrações sempre existiram e elas são o cerne do problema e parte da solução que envolve um service registry. Nos idos de 199x, quando eu comecei em TI, a forma mais comum de integrar aplicações era através de cargas. App1 gera dados em um formato conhecido por App2 em um horário T1 e App2 os processa em um horário T2, ou seja, não era online. App1 precisava saber quatro coisas sobre App2: os dados que queria, o formato que deveria ser disponibilizado, onde colocar os dados (qual o servidor FTP, pasta de rede, etc) e o horário limite para gerar todo o conjunto de informações.

Aos poucos o ambiente passou a requerer integrações online (blerg para esse termo) e surgiram os diferentes formatos de RPC (CORBA, DCOM, RMI, …), assim as aplicações (geralmente que compartilhavam uma mesma tecnologia) poderia invocar métodos remotos de aplicações na rede. Dessa forma, App1 precisava saber três informações sobre App2 (para o mesmo cenário anterior): os dados que queria, o formato que deveria ser disponibilizado e onde colocar os dados (qual o endpoint). O problema do horário foi resolvido pois agora era uma integração em tempo real.

Contudo, como dito anteriormente, essas tecnologias geralmente não permitiam muita interoperabilidade (CORBA resolvia isso) e tentaram abstrair demais problemas de sistemas distribuídos (procurar no Google sobre “The Eight Fallacies of Distributed Computing”), o que tornou algumas integrações problemáticas. Eu lembro quando o XML passou a ser a reposta para quase qualquer integração entre sistemas. Não que as outras técnicas não tivessem formas de representar dados (comparar CORBA com XML é o mesmo que maçã com banana – ah mas tem o XML-RPC), mas a combinação de XML com HTTP foi revolucionária por alguns fatores (que fogem ao escopo atual – que já está bem amplo). Nesse ponto App1 precisava saber ainda as mesmas três informações sobre App2 do que no exemplo acima, mas se fosse implementada a abordagem XML-RPC e o protocolo HTTP para transporte, a ideia de App1 ser na sua empresa e App2 ser na filial ou em um parceiro já se tornava mais viável.

Até aqui estamos nos idos dos anos dois mil, a era em que o HTTP tomou conta de tudo, veio a Web 2.0, B2B se tornou uma realidade entre muitas empresas e o software já era distribuído. Mas no datacenter a coisa era mais estanque. Os servidores ainda tinham um nome específico, as aplicações ainda eram modularizadas somente em biliotecas e as integrações entre aplicações da empresa geralmente eram feitas por bancos de dados (views). As aplicações cresceram e os servidores ganharam mais processamento e memória, qualquer TI que se prezasse pensava em escalabilidade (ou pelo menos redundância – dentro do datacenter). Era uma época interessante em que não se era xingado por ter o banco de dados, a aplicação e o servidor web em uma só máquina.

A evolução natural foi a serparação dos papéis, ter um proxy reverso, um servidor de aplicação e um servidor de banco de dados – tudo dedicado! oh! -, permitindo que crescessem cada parte de forma independente. Mas os servidores todos eram físicos, tinham nome e IPs bem-definidos e eram poucos. A virtualização acabou com isso. A gremlinizadora de servidores VMware tornou criar servidores uma coisa mais fácil e fez explodir o número deles no datacenter. SOA surgiu com força, marketing e todos começaram a fazer dos webservices a língua franca da integração entre aplicações. App1 ainda precisava das mesmas três informações sobre App2, mas agora, provavelmente, App1 rodava em cluster e App2 também. Havia outras questões em jogo, compartilhamento de memória, concorrência, paralelismo. Mesmo com clusters, o endpoint deveria ser conhecido, surgiram os ESBs e a coisa ficou feia e cara.

No início os ESBs eram um monolito que orquestrava uma miríade de serviços. Ele se tornou a peça central de uma arquitetura desenhada para ser distribuída e dinâmica. Eu penso que muita gente associou os termos SOA e ESB a elefantes brancos, que ninguém usa ou sabe para que serve ao certo (isso eu falo de mim que sou parte do público geral). Mas em 2006 uma empresa de fundo de quintal, a Amazon, começou a vender um serviço de cloud, as startups começaram a aparecer em sites de notícias como grandes usuárias desse tipo de serviço e as siglas terminadas em “aS” surgiram com força (SaaS, PaaS, IaaS). Algumas organizações compraram as ideias mágicas de private e hybrid cloud. Mas na nuven a vantagem é ser dinâmico, não ter o controle manual da infra, configurar o comportamento, fornecer o SLA e deixar a máquina gerenciar quantas instâncias são necessárias no momento para a carga de trabalho corrente.

E agora?! Perdi o determinismo da infra, perdi o controle dos meus servidores, meus pets, minha aplicação foi pulverizada nesse enxame de VMs (nem estou falando em containeres). Hoje eu diria que existe uma indústria de servidores dentro de cada datacenter (ou pelo menos deveria existir) e não conheço indústria com processos manuais, então, por que deveria uma aplicação ou uma infra ser feita de forma artesanal, que não garante homogeneidade, padrão e rapidez? Ainda mais em um mundo onde as aplicações estão mais segmentadas, especializadas e distribuídas, requerendo mais das equipes de infra? Sem falar que ainda se tem os mesmos três problemas para a integração da App1 com App2: qual é o endpoint, qual é o formato de dados e quais são os dados.

Os dois últimos problemas são resolvidos hoje geralmente com SOAP/XML e REST/JSON independentemente da tecnologia que adotarmos. O primeiro problema, do endpoint, hoje em dia é resolvido com utilização do protocolo HTTP, com uma URL (como antigamente). A diferença é que no passado a URL http://www.meudominio.com/app1 te levava de forma determinística ao servidor webserver01; hoje ela pode te levar tanto para o servidor huicdhuidc01.srv quanto para o UHuiHUgyuIMh769kIPO.srv, além disso, pode ser que daqui a cinco minutos o servidor UHuiHUgyuIMh769kIPO.srv não exista mais.

Eu diria que se esta não é a situação atual em que tua TI se encontra ou se encontrará em pouco tempo, talvez o Consul não seja o que estás procurando.

Ufa.

#end TLDR;

O Consul.io é um service registry, portanto ele se propõe a resolver o problema específico de descoberta de serviço, saber onde está disponível um determinado recurso na rede, qual a combinação IP:PORTA que me possibilita consumir um serviço.

Àqueles que leram o textão acima, esse componente arquitetural resolve o problema atual da infraestrutura dinâmica para aplicações, pois se os servidores podem ser criados e excluídos rapidamente, essas alterações afetam o endpoint onde um determinado serviço está acessível, não sabemos se o servidor de nome huds90372jdsdjios.srv existe agora ou existirá ainda daqui a cinco minutos, por isso precisamos de um recurso que informe a um load balancer ou diretamente a um cliente do serviço quais são os servidores que respondem nesse momento pelo endpoint que se deseja acessar.

Ele não é o único, há o Eureka por exemplo, mas foi do Consul que eu mais gostei por ser pequeno, não ter dependências externas (é feito em Go), ser simples de operar e ter uma interface DNS para consulta ao registro.

Preparei um laboratório, que está disponível em https://github.com/howtoseries/consul-demo para explicar o funcionamento dos agentes, simulando escala horizontal dos serviços em diferentes camadas e como eles se configuram automaticamente baseados nas informações contidas no Consul para quem quer ir para a mão na massa.

Quem quiser mais referências técnicas, como não curto ser repetitivo ou reinventar a roda (até porque já é uma ferramenta consolidada e possui um material muito bom disponível), vou deixar referências abaixo que são muito boas e que eu consumi:

Considerações pessoais

Como dito inicialmente, eu não penso que o Consul seja necessariamente uma ferramenta para microservices e justifico: ter webservices não é ter microservices, ter muitos servidores ou propiciar um ambiente que possa escalar de acordo com a demanda não é ter microservices e ter integração de aplicações através de webservices sem precisar de um proxy reverso (deixar um servidor poder “falar” com outro diretamente) também não é ter microservices e o Consul possibilita tudo isso.

Pode parecer idiota à primeira vista fazer as coisas que eu mencionei anteriormente, mas eu penso que há cenários diferentes que necessitam de soluções particulares, seja por cultura, seja por recursos humanos e/ou financeiros, seja por outro motivo qualquer.

Outro ponto importante sobre o Consul é ter atenção aos lançamentos de versão, pois funcionalidades ou mudanças de comportamento são introduzidos a cada minor release. Passei por isso pois implantamos a versão 0.6, que era a última, e foi lançada a 0.7 com algumas melhorias que precisávamos e fizemos ajustes através de configuração do serviço para resolver.

Além disso, é necessário entender muito bem o que os desenvolvedores pensaram quando optaram por protocolos como gossip e consensus, esse entendimento é vital ao se configurar o cluster. Também é vital a leitura da documentação de outage, há um texto bacana aqui que ilustra algumas possíveis pegadinhas.

Por último, mas não menos importante, aconselho que se experimente muito e com todos os cenários onde pretendes utilizar o Consul, teste o cluster, as falhas, as consultas e dedique tempo considerável para implantar a monitoria dos serviços com o agente. Se fizer isso, a garantia de se ter um ótimo service registry virá e com um bônus de se ter um sistema que tenha mais chance de sobreviver a falhas eventuais de nodos em mau funcionamento.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *