Desde o início da internet, automação tem sido um termo comum e aspiração para empresas que buscam constantemente por novos meios de reduzir o papel do ser humano no microgerenciamento de TI, permitindo que softwares executem tarefas automaticamente.
Isso levou ao nascimento de uma poderosa irmãzinha da automação, a orquestração. Orquestração é a automação não apenas de tarefas isoladas, mas também de redes, sistemas computacionais e fluxos de trabalho inteiros. Se automação é um veículo autônomo, orquestração é uma cidade autorregulada.
A orquestração se tornou rapidamente obrigatória para milhares de empresas que necessitam de automação e coordenação avançadas para lidar com as cargas massivas de servidores e demandas de alta velocidade ligadas à economia global da internet.
Nem é preciso dizer que o mercado cresceu muito nos últimos anos, e várias empresas se dedicaram a atender a essa necessidade, cada uma com abordagem própria de orquestração. Vamos dar uma olhada mais a fundo acerca de como essa tecnologia funciona e em algumas diferenças relevantes nas principais ofertas de produtos.
Infraestrutura de automação
No passado, toda infraestrutura de TI precisava ser gerenciada manualmente. Servidores tinham de ser instalados e configurados à mão, gerando alta sobrecarga e longos períodos de instalação. Isso tornava as empresas lentas e incapazes de se adaptar às mudanças com eficiência, visto que quaisquer atualizações na infraestrutura existente também tinham de ser tratadas de forma manual.
E, claro, se a empresa fosse grande o suficiente, com uma enorme força de trabalho de técnicos de TI, pequenas ocorrências de erro humano se acumulariam, enquanto inconsistências na manutenção do servidor levariam a aberrações e defeitos únicos, que teriam de ser padronizados manualmente…
Então chegou a infraestrutura como código (infrastructure as code)
Infraestrutura como código é exatamente o que o nome diz. É um código de alto nível que provisiona infraestrutura de TI automaticamente. Em algum momento veremos algumas de suas diferentes formas de funcionamento, mas, basicamente, é o molho secreto que torna a tecnologia de orquestração possível.
Uma vez que tudo está escrito em código – facilitando o transporte e a duplicação –, é possível provisionar 100 aplicações ou servidores idênticos na mesma quantidade de tempo que levaria a implementação manual.
A infraestrutura como código e os programas de orquestração pelos quais ela é controlada tornam a gestão de um negócio digital mais rápida, barata, consistente e segura (agora em tecnicolor!).
Mas nem todas as tecnologias de orquestração são criadas da mesma forma. Vamos mergulhar em algumas das maiores marcas e entender o que as move.
Puppet
É a mais antiga entre as tecnologias de grande nome, que remonta a 2005. Puppet é um nome estabelecido com um histórico comprovado de trabalho com clientes como Google, Reddit e Dell.
A Puppet se concentra no gerenciamento de configuração, o que significa que é projetada para lidar com a instalação e o gerenciamento de software em servidores pré-existentes. Ela usa uma configuração de agente e mestre, dois meios de controlar o fluxo de informações que geralmente andam de mãos dadas. O software dependente do mestre liga tudo a um servidor-mestre centralizado.
As mudanças na infraestrutura são feitas hierarquicamente, atualizando, primeiramente, o servidor-mestre, que comunica as mudanças do sistema a todos os seus servidores dependentes. Essa centralidade pode ser um bom privilégio, permitindo ao administrador visualizar e gerenciar tudo em um só local.
Ele também apresenta algumas desvantagens, como infraestrutura e manutenção aumentadas para executar o servidor-mestre extra, e fragilidades de segurança, devido às portas de comunicação entre o servidor-mestre e dependente, criando outro ponto de entrada que os invasores podem visar.
Parte integrante de seu servidor-mestre, a Puppet executa um tipo de software chamado “agente” em cada um de seus servidores dependentes. Ele reconfigura a infraestrutura no segundo plano de um servidor, executando as atualizações que extrai do servidor-mestre.
Os fãs do sistema acham que ele acelera um pouco o processo de atualização, mas pode exacerbar alguns dos problemas que um servidor-mestre já traz para a mesa, adicionando fragilidades de segurança e custos adicionais de manutenção. A adição desse software extra o torna um pouco mais volumoso, e a Puppet pode ser um pouco complicada de instalar em comparação com alguns dos produtos mais recentes.
A maturidade da Puppet dá estabilidade, mas não necessariamente agilidade, e nem sempre supera as correções de bugs com a mesma velocidade que você vê em empresas mais jovens na área. Se tudo isso não parece muito amigável para você, há uma área onde a Puppet torna as coisas mais fáceis.
A Puppet é configurada a fim de promover a codificação declarativa, um estilo em que o programador insere o resultado final desejado e o software descobre as etapas necessárias para que isso aconteça. Esse é um processo muito mais simples do que codificar manualmente as etapas necessárias para construir a infraestrutura desejada, e permite que você se concentre mais no que está tentando alcançar, enquanto a Puppet lida com o “como”.
Chef
O Chef surgiu em 2009 e tem muitas coisas em comum com a Puppet. É outra ferramenta que se concentra no aspecto de gerenciamento de configuração da orquestração e é construída de forma semelhante para receber pedidos de um servidor-mestre e executar software de agente em seus servidores dependentes.
Isso significa que o Chef compartilha alguns dos pontos fracos da Puppet, incluindo dificuldades de configuração inicial, aumento dos custos de manutenção e outros pontos fracos de segurança. A maior diferença entre Chef e Puppet é a abordagem do Chef em relação ao estilo de codificação.
A abordagem é mais tradicional do que o estilo declarativo da Puppet, exigindo que os programadores escrevam um plano detalhado de como desejam construir a infraestrutura, em vez de deixar o Chef cuidar de cada parte do processo para eles, o que faz dele uma solução menos amigável do que a Puppet, pois requer mais tempo e esforço por parte do programador.
Mas, se você é mestre nos códigos e gosta de quebrar paradigmas, o código do Chef pode oferecer grande flexibilidade e mais controle sobre sua visão do que você encontraria na Puppet.
Ansible
Maior do que o Chef e a Puppet, o Ansible surgiu em 2012 e rapidamente começou a superar seus antecessores, atraindo clientes relevantes como DigitalOcean e 9Gag. A popularidade provavelmente se dá pelo fato de que o Ansible soa fácil de usar logo de início.
Diferentemente dos predecessores, o Ansible funciona sem mestre nem agente, o que faz dele um pacote de instalação muito mais elegante e capaz de reduzir custos de manutenção e eliminar riscos de segurança. Eles conseguiram se livrar do modelo de servidor-mestre configurando seus servidores para se comunicarem diretamente entre si via protocolo SSH (Secure Socket Shell).
Esse é um modelo mais seguro, embora alguns usuários achem que a conexão SSH é executada um pouco mais lentamente em comparação com servidores com agente. Ansible também é mais fácil de programar. Ele usa um emissor YAML Python para sua configuração, uma linguagem de programação mais intuitiva do que o Ruby do Chef ou a linguagem de codificação personalizada da Puppet.
O Ansible usa código imperativo, portanto, embora sua linguagem de programação seja intuitiva, você ainda precisa trabalhar para codificar as etapas de seu projeto sozinho.
Saltstack
Saltstack é uma solução coexistente com o Ansible que surgiu em 2011, e ambas são bastante comparadas entre si, da mesma forma que Chef e Puppet. Assim como o Ansible, o Saltstack usa YAML, então é outra boa opção para quem procura fugir de algumas linguagens de programação mais complexas.
O Saltstack usa uma rede com agente e mestre, embora tenha opções para rodar sem mestre, utilizando conexões SSH, no mesmo estilo que o Ansible. Porém, é provável que você não goste de fazer isso, pois 1) o Ansible dedicou muito tempo aperfeiçoando o seu sistema, e 2) a principal atração do Saltstack é sua velocidade de iteração, obtida com a implantação eficiente de seus agentes Salt Minion (se você está aqui pela ferramenta de orquestração com o nome de agente mais bonito, não procure mais).
Ele vem com as preocupações usuais de modelo de agente, um pacote de instalação mais volumoso e um ponto de ataque adicional. O Saltstack usa um pacote pycrypto que oferece boa segurança, não tão complexo quanto as conexões SSH do Ansible, mas ainda assim decente. Ele suporta um estilo declarativo, que, junto à sua linguagem de configuração intuitiva, ajuda a facilitar as coisas para o programador.
Terraform
Terraform é como uma espécie animal totalmente distinta, a ponto de não se enquadrar na mesma categoria que os demais. Lançado em 2014, Terraform foi construído a partir de um conjunto de prioridades diferente de Chef, Puppet, Ansible e Saltstack, focando em provisionar infraestrutura em vez de gerenciamento de configuração – e esses são dois trabalhos diferentes que as pessoas costumam considerar.
O gerenciamento da configuração é necessário para manter a infraestrutura pré-existente e configurá-la como o programador deseja. Provisionamento é necessário para configurar a infraestrutura de TI em primeiro lugar, seja uma plataforma, seja um pedaço de software, seja um servidor inteiro.
A maioria das ferramentas de gerenciamento de configuração pode fazer um pouco de provisionamento, e o Terraform pode lidar com o gerenciamento de configuração até certo ponto, mas ambos funcionam melhor quando permanecem em suas respectivas vias.
O que separa o Terraform do resto do pacote, também, é a sua infraestrutura imutável. Saltstack, Chef, Puppet e Ansible, todos usam infraestrutura mutável. A diferença só vem à tona quando você deseja atualizar sua infraestrutura. A mutável é atualizada incorporando o update à infra existente e faz as mudanças necessárias para trazê-la ao novo estado desejado.
É uma maneira bem comum de lidar com atualizações, mas, conforme você acumula atualizações na mesma infraestrutura, tem uma chance pequena, mas crescente, de desvio de configuração, idiossincrasias únicas que tornam os bugs de configuração mais difíceis de diagnosticar e eliminar.
A infraestrutura imutável resolve esse problema não atualizando, de fato, a sua infra. Em vez disso, quando uma nova atualização é necessária, a nova infraestrutura é provisionada com a atualização integrada, e, em seguida, o tráfego é transferido da antiga para a nova, criando uma infraestrutura mais padronizada e duplicável.
Isso pode trazer seus próprios problemas, incluindo a necessidade de maior poder de processamento ao fazer uma atualização e a possibilidade de quaisquer dados locais na infraestrutura inicial serem perdidos quando você a substitui por uma nova.
O Terraform achou meios de contornar o segundo problema, encontrando soluções de armazenamento de dados não locais, embora isso possa exigir que mais espaço seja ocupado para criar um hub de dados que tanto a velha quanto a nova infraestrutura possam acessar.
Vale ressaltar que algumas das outras ferramentas de orquestração também podem ser configuradas para uma abordagem imutável, mas não é natural. Como o Ansible, o Terraform não tem agente nem mestre, o que facilita sua ativação e execução. Como a Puppet e o Saltstack, ele usa código declarativo.
Resumindo, é muito fácil de usar, e, se você está procurando provisionar infraestrutura, é uma ótima ferramenta para trabalhar.
Edge Orchestrator
Aqui na Azion Technologies, nos interessamos por uma solução de orquestração para gerenciar nossa ampla rede de ponta sem servidor. Nenhuma das ofertas existentes atende às nossas necessidades, então, criamos a nossa própria, o Azion Edge Orchestrator.
Diferentemente dos produtos discutidos aqui, o Azion Edge Orchestrator foi projetado com foco no gerenciamento dos nós sem servidor que constituem a borda. Isso significa que não estamos realmente procurando servir a mesma função de produtos como Ansible ou Terraform, pois operamos em um espaço novo e diferente, mas ainda tentamos abraçar e construir em cima das inovações que vieram antes.
Ficamos realmente impressionados com as velocidades de iteração que o Saltstack alcançou com sua conexão com agente, mas não estávamos satisfeitos com as questões de segurança inerentes ao relacionamento de agente-mestre. Em vez de descartar totalmente o modelo, como o Ansible e o Terraform seguiram, decidimos torná-lo nosso.
O sistema com agente do Azion Edge Orchestrator é protegido contra ataques externos por criptografia de ponta a ponta e camadas de segurança baseadas em tokens. Nossos agentes nos dão o poder de provisionamento zero-touch, permitindo ao usuário provisionar e configurar de forma rápida e remota os Edge Nodes em sua rede.
Esse provisionamento zero-touch aumenta drasticamente a escalabilidade da rede, facilitando a instalação rápida e uniforme de edge applications e firewalls direto da Azion ou de terceiros, por meio do Azion Marketplace.
O Edge Orchestrator usa código mutável, o que significa que lidamos com alguns dos mesmos problemas de desvio de configuração que produtos como Ansible e Puppet sofrem. Instalamos contingências de reversão para que os nós que apresentam mau comportamento sejam redefinidos para sua versão antiga. Isso funciona muito bem, mas não é perfeito. Por fim, priorizamos a segurança e a preservação dos dados do cliente e descobrimos que o código mutável não deixava possibilidade de perda de dados.
Por último, somos grandes fãs da maneira como o Terraform se concentra na facilidade de uso para seus clientes – e, se você não consegue vencê-los, junte-se a eles. O Edge Orchestrator tem um foco semelhante em começar as coisas de maneira simples, padronizando para um estilo declarativo quando você primeiro provisiona seus Edge Nodes e, em seguida, abre caminho para abordagem imperativa mais específica conforme o programador mergulha na edição e personalização de Edge Services.
Resumo
A tecnologia de orquestração é uma ferramenta cuja eficiência é super empolgante, e já é uma virada de jogo na maneira como as empresas gerenciam a área de TI. É claro que toda empresa quer dizer que sua ferramenta é a melhor, mas o realmente ótimo é que a flexibilidade das opções modernas significa que, sejam quais forem suas necessidades exclusivas, há um produto disponível para você.
Se você está procurando um provisionamento ágil e fácil que colocará sua infraestrutura online o mais rápido possível, talvez os serviços do Terraform sejam boas opções.
Imagine-se um mestre da programação que queira dedicar seu tempo para projetar sua ferramenta de gerenciamento de configuração de acordo com suas especificações exatas? Você pode gostar de testar o código intrincado do Chef.
E se você está livre das restrições dos sistemas de servidor tradicionais e está pronto para impulsionar seu desempenho no Edge da rede, então o Edge Orquestrador pode ser a escolha certa.
