Comparando a entrega de aplicações: 2005 vs. 2015

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

James Ward, que escreve código (segundo a própria descrição), recentemente escreveu um excelente artigo no qual comparou a implantação de aplicações hoje com a de dez anos atrás. Um dos segredos mais bem guardados do setor de TI em geral é que as mudanças nas arquiteturas e na implantação de aplicações têm impacto direto na entrega de aplicações (o processo de garantir que elas sejam rápidas, seguras e estejam disponíveis para seus usuários). As mudanças promovidas atualmente pelos microsserviços, por exemplo, são significativas na forma como irão mudar a arquitetura de rede e também seu modelo de implantação.

Eu sei, eu sei. Você está pensando que a adoção de microsserviços, conteinerização e nuvem abstrai a rede, tornando as aplicações menos dependentes dela. E isso é verdade, do ponto de vista dos desenvolvedores e talvez até mesmo da equipe de 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 continuam sendo responsáveis por muitas funções que tornam as aplicações rápidas, mantêm sua segurança e garantem sua disponibilidade. Portanto, mudanças no local e na forma como as aplicações são compostas e implantadas necessariamente afetam esses serviços, mesmo que a aplicação não saiba que eles existem (e, sinceramente, ela nunca deveria saber. Nesse sentido, eles são como anjos da guarda.)

Portanto, considerando essa relação, mesmo que ela não seja correspondida pela aplicação, o artigo de James inspirou uma análise paralela das mudanças na forma como entregamos aplicações nos últimos dez anos.

Arquitetura de implantação

2005	2015
Linha de conga	Plataforma

Em 2005, as equipes de rede (NetOps) implantavam os diversos serviços de aplicação necessários para disponibilizar aplicações no que costumamos chamar de “fila de conga”. Eram soluções pontuais e independentes. Se fosse necessário acelerar uma aplicação, implantava-se um produto de otimização de desempenho da Web em um equipamento próprio e dedicado. Outro equipamento para balanceamento de carga, outro para segurança de aplicações e assim por diante. Com o tempo, formaram-se longas filas de equipamentos, e o tráfego precisava passar por cada um deles nos dois sentidos.

Em 2004, surgiram os controladores de entrega de aplicações (embora ainda fossem muito imaturos em 2005), que começaram a evoluir para o que temos hoje: uma plataforma. Essas plataformas oferecem funcionalidades e processamento comuns e podem ser ampliadas com módulos (ou plug-ins, complementos ou como você preferir chamá-los). A abordagem de plataforma reduz significativamente o tempo gasto “na rede”, assim como a conteinerização e a virtualização reduzem o tempo de comunicação entre aplicações e serviços. Ela também permite reduzir os custos operacionais ao compartilhar uma base comum — a plataforma — que padroniza o gerenciamento dos diversos serviços de aplicação necessários para disponibilizar uma aplicação atualmente.

A evolução de produto para plataforma é vantajosa à medida que a implantação de aplicações avança para arquiteturas mais descartáveis e decompostas, que aproveitam tecnologias emergentes, como contêineres e microsserviços, e para a implantação em ambientes de nuvem, pois essas plataformas podem ser usadas para implantar diversos serviços de aplicação, ou apenas um, utilizando o mesmo núcleo padronizado. Isso significa menos sobrecarga administrativa à medida que a presença dos serviços de aplicação implantados aumenta, além da possibilidade de adicionar serviços conforme necessário à medida que as aplicações crescem.

Métodos de implantação

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

Em 2005, as interfaces gráficas baseadas na Web estavam apenas começando a se tornar padrão, e o principal método de provisionamento e configuração de serviços de aplicativos era por meio da CLI. Esse processo, como todos os processos manuais, era demorado e, à medida que os serviços de aplicativos se tornavam mais complexos, exigia ainda mais tempo. A ocorrência de problemas causados por erro humano e o impacto resultante (por estar na rede, uma configuração incorreta aumenta exponencialmente a área afetada) exigiam supervisão, o que consumia ainda mais tempo. Copiar e colar era uma prática comum, mas não infalível, e a sobrecarga administrativa do gerenciamento de serviços era significativa o bastante para que apenas os aplicativos mais importantes tivessem acesso aos benefícios desses serviços.

Avançando para 2015 e para a revolução do DevOps. A programabilidade — tanto em APIs quanto em configurações baseadas em modelos — está mudando tudo, inclusive na rede. Agora, os serviços de aplicações podem ser automatizados por meio de APIs usando frameworks populares como Puppet e Chef, pré-integrados a soluções de orquestração como Cisco APIC e VMware NSX, além de serem personalizados com Python, Perl, bash e curl. Os modelos de serviços de aplicações permitem a padronização e a reutilização, além de incentivar o tratamento da infraestrutura “como código”, possibilitando que as práticas de entrega contínua se estendam à rede.

Embora ainda não seja tão difundida quanto a entrega contínua no desenvolvimento de aplicações, a entrega de aplicações evoluiu (e continua evoluindo) para oferecer opções de implantação programáveis que reduzem o tempo de lançamento no mercado por meio do provisionamento mais rápido de serviços, além de diminuir os custos operacionais por meio da automação e da reutilização.

Formatos de implantação

2005	2015
Mainframe	Virtualizado

Em 2005, começou a corrida para desenvolver equipamentos de rede maiores, melhores, mais rápidos e com mais recursos. O aumento das velocidades da Ethernet e a explosão de aplicações baseadas na Web exigiram a expansão correspondente dos equipamentos de grande porte implantados na rede para atender aos requisitos dos serviços de aplicações.

Hoje, o foco está na densidade e na utilização otimizada dos recursos. Isso significa virtualização e computação em nuvem, ambas viabilizadas pela virtualização das plataformas de entrega de aplicações. Atualmente, as plataformas de entrega de aplicações podem ser implantadas em ambientes de nuvem como AWS, Microsoft Azure e Rackspace, bem como na forma de um appliance virtual que pode ser implantado em hardware dedicado ou convencional. Esse recurso é necessário não apenas para oferecer suporte a ambientes de nuvem, mas também para se adaptar a arquiteturas emergentes, como microsserviços. Hoje, os próprios microsserviços e servidores 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 de 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 adequar, em escala, a um modelo imutável e descartável. Muitas plataformas de entrega de aplicativos já chegaram a esse ponto e, combinadas com opções de implantação programáveis, estão prontas para enfrentar o desafio.

Responsabilidade pela implantação

Em 2005 — e ainda hoje em muitas organizações —, a equipe de redes era totalmente responsável pela implantação e pelo gerenciamento da entrega de aplicações. Todos os aspectos da entrega, desde a aquisição até o provisionamento e a configuração, eram — e muitas vezes ainda são — tratados pelas operações de rede. Esse modelo fragmentado gerava atrasos enquanto os requisitos eram discutidos, os chamados eram abertos e os engenheiros provisionavam e configuravam manualmente os serviços de aplicação necessários para disponibilizar um aplicativo.

Hoje, essa ainda é a realidade em muitas organizações, mas o impacto da nuvem e dos microsserviços, aliado à adoção de DevOps, está mudando esse cenário. Há uma forte demanda por TI como serviço, com a responsabilidade pela configuração dos serviços de aplicações sendo transferida para as equipes de operações ou até mesmo de desenvolvimento. Os serviços associados às aplicações precisam estar localizados mais próximos delas, tanto física quanto topologicamente. Isso coloca o DevOps definitivamente no comando e o torna responsável pelo provisionamento e pela configuração desses serviços.

Isso não significa que a equipe de rede esteja se eximindo da responsabilidade pela entrega de aplicações. Há um número significativo de aplicações e questões corporativas que exigem que os serviços de aplicações sejam fornecidos de maneira mais tradicional e com foco na confiabilidade, em vez da agilidade. Esses serviços ainda são, e provavelmente continuarão sendo, responsabilidade da equipe de rede. Mas outros estão passando e continuarão a passar para a responsabilidade de DevOps.

A entrega de aplicações avançou muito nos últimos dez anos. Ela evoluiu de um conjunto de produtos para uma plataforma unificada, ganhou capacidade de programação e deixou de depender de grandes equipamentos dedicados, passando a oferecer suporte a hipervisores e à implantação na nuvem. À medida que aplicações móveis, microsserviços e DevOps continuam transformando radicalmente a forma como as aplicações são criadas, implantadas e entregues, é de se esperar que os serviços responsáveis por sua entrega continuem evoluindo para mantê-las rápidas, seguras e disponíveis.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie