Comparando a entrega de aplicativos: 2005 vs 2015

James Ward, que escreve código (sua descrição), escreveu recentemente um ótimo artigo no qual comparou a implantação de aplicativos hoje em comparação com dez anos atrás. Um dos segredos mais bem guardados do setor de TI em geral é que mudanças nas arquiteturas e na implantação de aplicativos têm um impacto direto na entrega de aplicativos (o processo real de garantir que os aplicativos sejam rápidos, seguros e disponíveis para seus consumidores). As mudanças que estão sendo promovidas hoje pelos microsserviços, por exemplo, são significativas na forma como elas vão mudar a arquitetura da rede , bem como seu modelo de implantação.

Eu sei, eu sei. Você está pensando que a mudança em direção aos microsserviços, à conteinerização e à nuvem abstrai a rede, tornando os aplicativos menos dependentes deles. E isso é verdade, da perspectiva dos desenvolvedores e talvez até mesmo das operações. Mas uma rede ainda é necessária; os dados trocados ainda precisam fluir por esses canais e os serviços que residem na rede ainda são responsáveis por muitas funções que tornam os aplicativos rápidos, os mantêm seguros e garantem a disponibilidade . Mudanças em onde e como os aplicativos são compostos e implantados necessariamente impactam esses serviços, mesmo que o aplicativo não esteja ciente de sua existência (e honestamente, ele nunca deveria saber). Eles são como anjos da guarda nesse sentido.)

Então, dada a relação, mesmo que não seja correspondida pelo aplicativo, o artigo de James inspirou uma análise paralela das mudanças na forma como entregamos aplicativos nos últimos dez anos.

Arquitetura de Implantação

2005	2015
Linha de conga	Plataforma

Em 2005, as equipes de rede (NetOps) implantaram os vários serviços de aplicativos necessários para entregar aplicativos no que gostamos de chamar de “conga line”. Essas eram soluções pontuais individuais. Se você precisasse de algo para tornar aquele aplicativo mais rápido, você implantaria um produto de otimização de desempenho da web em sua própria caixa pessoal e privada. Outra caixa para balanceamento de carga, outra para segurança de aplicativos e assim por diante. Por fim, havia longas filas com muitas caixas, cada uma das quais tinha que ser atravessada em ambas as direções. 

Em 2004, os controladores de entrega de aplicativos surgiram (mas eram muito imaturos em 2005) e começaram a evoluir para o que temos hoje, que é uma plataforma . Essas plataformas fornecem funcionalidade e processamento comuns e podem ser estendidas com módulos (ou plug-ins, complementos ou como você preferir chamá-los). A abordagem de plataforma reduz muito o tempo gasto “na rede”, da mesma forma que a conteinerização e a virtualização reduzem a quantidade de tempo gasto viajando entre aplicativos e serviços. Ele também oferece a capacidade de reduzir custos operacionais ao compartilhar uma base comum – a plataforma – que normaliza o gerenciamento entre os vários serviços de aplicativos necessários para entregar um aplicativo hoje.

A evolução do produto para a plataforma é vantajosa à medida que a implantação de aplicativos avança para arquiteturas mais descartáveis e decompostas, aproveitando tecnologias emergentes como contêineres e microsserviços, e a implantação em ambientes de nuvem, porque eles podem ser usados para implantar uma variedade de serviços de aplicativos, ou apenas um, usando o mesmo núcleo padronizado. Isso significa menos sobrecarga administrativa à medida que a área de cobertura dos serviços de aplicativos implantados se expande e a capacidade de adicionar serviços conforme necessário conforme os aplicativos crescem.

Métodos de Implantação

2005	2015
Implantação manual	Implantação programável

Em 2005, GUIs baseadas na web estavam apenas entrando em uso padrão e o método primário de provisionamento e configuração de serviços de aplicativos era por meio da CLI. Esse processo, como todos os processos manuais, levava tempo e, à medida que os serviços de aplicativos ficavam mais complexos, levava ainda mais tempo. A introdução de problemas devido a erro humano e o impacto resultante (estar na rede aumenta exponencialmente o raio de explosão de configuração incorreta) significava que a supervisão demorava ainda mais tempo. Copiar e colar era comum, mas não infalível, e a sobrecarga administrativa de gerenciamento de serviços era significativa o suficiente para garantir que apenas os aplicativos mais importantes tivessem acesso aos benefícios desses serviços.

Avançando para 2015 e a revolução DevOps. A programabilidade – tanto em APIs quanto em configurações baseadas em modelos – está mudando tudo, até mesmo na rede. Os serviços de aplicativos agora podem ser automatizados por meio de APIs usando estruturas populares como Puppet e Chef, pré-integradas com soluções de orquestração como Cisco APIC e VMware NSX, e personalizadas por Python, Perl, bash e curl. Os modelos de serviço de aplicativo permitem padronização, reutilização e incentivam o tratamento da infraestrutura “como código” para permitir que práticas de entrega contínua se estendam para a rede.

Embora não seja tão onipresente quanto a entrega contínua no desenvolvimento de aplicativos, a entrega de aplicativos evoluiu (e continua evoluindo) para oferecer suporte a opções de implantação programáveis que reduzem o tempo de colocação no mercado por meio de provisionamento de serviços mais rápido, além de reduzir o custo operacional por meio de automação e reutilização.

Fatores de forma de implantação

2005	2015
Ferro Grande	Virtualizado

Em 2005, a pressa era construir hardware de rede maior, melhor, mais rápido e mais capaz. O aumento da velocidade da Ethernet e uma explosão de aplicativos baseados na web significaram uma expansão complementar do grande hardware implantado na rede para dar suporte aos requisitos de serviços de aplicativos.

Hoje o foco está na densidade e na utilização ideal dos recursos. Isso significa virtualização e computação em nuvem, ambas suportadas pela virtualização de plataformas de entrega de aplicativos. As plataformas de entrega de aplicativos agora podem ser implantadas em ambientes de nuvem como AWS, Microsoft Azure e Rackspace, bem como em um dispositivo virtual implantável em hardware específico ou pronto para uso. Essa capacidade é um requisito, não apenas para dar suporte a ambientes de nuvem, mas para se adaptar a arquiteturas emergentes, como microsserviços. Os microsserviços e os próprios servidores hoje são, como observa James Ward, “descartáveis, imutáveis e efêmeros…. “

Isso significa que muitos dos serviços de aplicativos que estão migrando para o domínio do DevOps – balanceamento de carga, segurança de aplicativos e otimização – devem atender aos critérios de um data center definido por software . No mínimo, eles devem ser capazes de se encaixar em um modelo imutável e descartável em escala. Muitas plataformas de entrega de aplicativos já existem hoje e, combinadas com opções de implantação programáveis, estão prontas para enfrentar o desafio.

Responsabilidade de Implantação

Em 2005 — e em muitas organizações ainda hoje — a equipe de rede é totalmente responsável por implantar e gerenciar a entrega de aplicativos. Cada aspecto da entrega, desde a aquisição até o provisionamento e a configuração, era e muitas vezes ainda é tratado pelas operações de rede. Esse modelo desarticulado significava atrasos à medida que os requisitos eram definidos, os tickets eram criados e os engenheiros provisionavam e configuravam manualmente os serviços de aplicativo necessários para entregar um aplicativo.

Hoje em dia, isso ainda acontece em muitas organizações, mas o impacto da nuvem e dos microsserviços combinados com a adoção do DevOps está mudando isso. O desejo por TI como serviço é forte, com uma mudança na responsabilidade pela configuração de serviços de aplicativos para equipes de operações ou mesmo de desenvolvimento. Há uma necessidade de que serviços afins de aplicativos sejam localizados física e topologicamente mais próximos do aplicativo. Isso coloca o DevOps firmemente no assento do motorista e responsável por provisionar e configurar esses serviços.

Isso não significa que a equipe de rede esteja lavando as mãos na entrega de aplicativos. Há um segmento significativo de aplicativos e preocupações corporativas que exigem serviços de aplicativos entregues de uma maneira mais tradicional, com foco em obter confiabilidade em vez de agilidade. Esses serviços ainda estão, e provavelmente permanecerão, no domínio da equipe de rede. Mas outras são e continuarão sendo responsabilidade do DevOps.

A entrega de aplicativos evoluiu muito nos últimos dez anos. Ele evoluiu de um conjunto de produtos para uma plataforma unificada, ganhou programabilidade e se transformou de um grande hardware para oferecer suporte a hipervisores e implantação em nuvem. À medida que os aplicativos móveis, os microsserviços e o DevOps continuam a mudar radicalmente a maneira como os aplicativos são criados, implantados e entregues, espere ver uma evolução contínua dos serviços que, em última análise, entregam esses aplicativos e os mantêm rápidos, seguros e disponíveis.