O ADC pronto para a nuvem

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

Um controlador de entrega de aplicações (ADC) preparado para a nuvem não é um ADC tradicional. Disponível para implantação em hardware personalizado ou COTS, ele é uma solução de software escalável que atende à necessidade de entrega e implantação de aplicações de forma rápida, segura e com alta disponibilidade. Um ADC preparado para a nuvem viabiliza uma abordagem moderna em duas camadas para arquiteturas de data center, combinando estabilidade, segurança e escalabilidade tradicionais com recursos programáticos modernos, flexíveis, voltados para a nuvem e compatíveis com DevOps.

É uma boa descrição, mas o que isso significa?

Já escrevi anteriormente sobre o que é necessário para ser considerado um proxy de aplicações moderno e isso certamente faz parte do que um ADC preparado para a nuvem exige. No entanto, os ambientes exigentes de hoje precisam de mais do que apenas recursos técnicos: precisam de integração operacional e com o ecossistema, além da capacidade de oferecer suporte a arquiteturas de aplicações modernas e emergentes.

E, sinceramente, há muitos ADCs no mercado que fariam as mesmas alegações de estarem preparados para a nuvem e oferecerem suporte a arquiteturas de aplicações tradicionais e emergentes, entre outras afirmações. Por isso, hoje gostaria de analisar mais a fundo o que diferencia um ADC preparado para a nuvem de um ADC tradicional, antes de explorarmos melhor por que ele é tão importante no cenário atual das aplicações.

Cinco níveis de diferenciação

Existem basicamente cinco (seis, se quisermos ser realmente rigorosos) maneiras diferentes pelas quais um ADC preparado para a nuvem se diferencia de um ADC tradicional. E como a F5 praticamente definiu o que um ADC deveria ser muito antes de eu chegar aqui, podemos dizer que entendemos de ADCs melhor do que ninguém — tanto o que eles precisavam ser quanto aquilo em que devem evoluir para continuar entregando aplicações com a velocidade, a segurança e a estabilidade de que as empresas precisam.

Desempenho

É óbvio, certo? Afinal, se você vai ficar à frente dos aplicativos e atuar como proxy para eles, é melhor ser rápido (ou, melhor ainda, mais rápido) do que os aplicativos que está disponibilizando. Os ADCs tradicionais são fornecidos no formato de appliances: chassis, hardware, equipamentos. Ainda assim, eles são limitados pelas CPUs do hardware personalizado com o qual precisam trabalhar. Como os ADCs são plataformas, eles tendem a priorizar a velocidade geral, assim como as CPUs de uso geral priorizam o processamento genérico. No entanto, quase sempre incluem diversas opções de aceleração por hardware que precisam ser definidas antes da implantação. Talvez pareça loucura, mas acreditamos que um ADC pronto para a nuvem deve ser capaz de superar essa limitação, entendendo que um aplicativo pode precisar mais de um serviço do que de outro, enquanto outro aplicativo pode ter necessidades diferentes. Assim como a própria ideia de realocar recursos computacionais sob demanda, que sustenta todo o conceito de computação em nuvem, as organizações que investem em qualquer tipo de hardware também devem poder redirecioná-lo para outras finalidades.

A razão pela qual isso é importante em serviços executados sobre a rede é que transferir tarefas comuns para hardware específico (FPGAs) libera a CPU para realizar outras atividades, como inspeção, modificação e filtragem de solicitações e respostas etc. Isso torna toda a “parada” no proxy mais rápida, o que se traduz em menor latência e usuários mais satisfeitos.

É por isso que um ADC preparado para a nuvem pode romper barreiras, aproveitando o desempenho definido por software e permitindo que as organizações aumentem programaticamente o desempenho do ADC para determinados tipos de processamento, como segurança. Isso significa que, se as necessidades da organização mudarem, o perfil de desempenho desse hardware também poderá ser alterado sob demanda. Isso é agilidade no hardware. Eu sei, parece paradoxal, não é? Mas isso faz parte de um ADC preparado para a nuvem: a capacidade de redirecionar o uso de hardware especializado, protegendo os investimentos e eliminando a necessidade de atualizações caras que exijam a substituição completa dos equipamentos.

Programabilidade

Uma frustração antiga que, pessoalmente, ouvi repetidas vezes dos clientes é a falta de sintonia entre NetOps e DevOps quando se trata de recursos de criação de scripts. O problema é que o ADC tradicional oferecia apenas os recursos mais básicos de scripting, em linguagens mais familiares para NetOps do que para DevOps. Ainda assim, as equipes de DevOps estavam dispostas a aprender para aproveitar o uso de scripts no caminho de dados, pois isso possibilitava diversas formas mais ágeis de roteamento de solicitações e respostas, estratégias de escalabilidade e até mesmo serviços de segurança. Porém, com o ADC tradicional instalado a montante, no núcleo da rede, as equipes de NetOps não permitiriam que DevOps implantasse scripts que pudessem interferir no fluxo do tráfego.

A disponibilidade de edições virtuais significava que as equipes de DevOps agora tinham acesso ao seu próprio ADC pessoal e privado na forma de uma máquina virtual, mas ainda eram obrigadas a aprender uma linguagem de script voltada para redes. Isso não é bom. Um ADC preparado para a nuvem deve oferecer suporte tanto às equipes de NetOps na rede principal quanto às de DevOps na rede de aplicativos, como na nuvem. E as equipes de DevOps, especialmente os desenvolvedores, preferem linguagens mais adequadas ao desenvolvimento, como node.js. Não apenas porque conhecem a linguagem, mas também porque já existe um amplo repositório de bibliotecas (como NPM) e serviços que permitem uma integração mais rápida com uma infraestrutura voltada para desenvolvedores. É por isso que um ADC preparado para a nuvem deve oferecer suporte a ambos.

Segurança do aplicativo

Há muito tempo, os ADCs tradicionais oferecem segurança básica para aplicações. Por estarem posicionados à frente de uma aplicação, especialmente de aplicações web, eles geralmente eram (e ainda são) o primeiro componente do data center capaz de reconhecer um ataque e tomar alguma medida a respeito. Como seria de esperar, a maior parte dessa segurança se concentrava na proteção em nível de protocolo. A proteção contra ataques SYN flood, a detecção de DDoS e outras opções de segurança relacionadas a TCP e HTTP básico já fazem parte dos ADCs tradicionais há algum tempo.

Mas um ADC preparado para a nuvem deve ir além. É provável que ele seja um dos poucos "dispositivos" incluídos na própria arquitetura do aplicativo para garantir a inevitável escalabilidade exigida pelas aplicações atuais. Portanto, faz todo o sentido dar a mesma atenção à segurança de toda a pilha. Pelo menos é o que pensamos, especialmente porque isso melhora o desempenho. Se for preciso interromper o fluxo para realizar um tipo de processamento, faz sentido executar o máximo possível de tarefas ao mesmo tempo. Isso é mais eficiente e elimina a latência causada pelo tráfego de um equipamento para outro e depois para outro. Se você já fez uma viagem longa com crianças, sabe do que estou falando. Há um banheiro no posto de gasolina. Você não vai querer parar novamente em uma área de descanso cinco minutos depois, certo? O mesmo vale para a segurança da rede. Faça o máximo possível de uma só vez para eliminar a sobrecarga, que muitas vezes é motivo de frustração tanto para os clientes quanto para a empresa. O desempenho é fundamental, e um ADC preparado para a nuvem deve fazer tudo o que puder para proporcionar experiências mais rápidas nos aplicativos.

Isso pode significar oferecer novos modelos para gerenciar a crescente demanda (e, em alguns casos, a exigência) de oferecer suporte a comunicações seguras entre dispositivos móveis e aplicativos. Isso significa oferecer suporte ao Forward Secrecy (FS) e à criptografia que o viabiliza. Significa viabilizar novos modelos para transferir o processamento computacionalmente dispendioso de criptografia e descriptografia para o hardware projetado para executá-lo, sem comprometer as arquiteturas necessárias para oferecer suporte a microsserviços e aplicativos emergentes. Um ADC pronto para a nuvem deve oferecer suporte a ambos, possibilitando comunicações rápidas e seguras, ao mesmo tempo que se integra perfeitamente às arquiteturas e aos ambientes de nuvem atuais.

Ecossistema de parceiros e automação

A economia da Outra API é fundamental para o sucesso da nuvem privada e para a vantagem competitiva proporcionada às empresas pelo aumento da automação e da orquestração. Mas, por mais conveniente que fosse, sempre haverá uma variedade de serviços de diferentes fornecedores no data center, cada um com seus próprios modelos de integração e de objetos. Isso muitas vezes resulta em uma automação complexa orientada por APIs, que exige conhecimento especializado em todos os componentes necessários. Na prática, são necessários dois níveis de integração: um para orquestração e outro para automação (não, elas não são a mesma coisa). Há os recursos de automação inerentes à plataforma, por meio de APIs e modelos, e há também a integração nativa com o ecossistema de parceiros, no qual a orquestração é predominante. Ambos são necessários em um ADC pronto para a nuvem. O primeiro garante a automação por meio de produtos proprietários ou scripts personalizados e frameworks como Puppet e Chef, enquanto o segundo viabiliza a orquestração por meio de controladores cada vez mais importantes, como OpenStack, VMware e Cisco.

Um ADC preparado para a nuvem deve oferecer integração nativa e orquestração por meio dos frameworks e sistemas utilizados para fornecer uma solução abrangente de orquestração.

Não deveria ser necessário dizer mais de uma vez que um ADC preparado para a nuvem deve oferecer suporte a modelos de nuvem.

Então, isso é tudo o que vou dizer sobre o assunto.

Modelo do aplicativo

Os ADCs tradicionais surgiram da necessidade de oferecer um conjunto robusto de serviços para aplicações tradicionais. Monólitos, por assim dizer. As aplicações atuais estão cada vez mais distribuídas, diversificadas e distintas de suas antecessoras tradicionais, aproveitando uma variedade de arquiteturas, plataformas e modelos de implantação. Seja em contêineres ou máquinas virtuais, na nuvem ou em ambientes semelhantes à nuvem, as aplicações ainda precisam de alguns desses serviços. E, quando há necessidade de mais de um serviço ao mesmo tempo (como, por exemplo, balanceamento de carga e segurança de aplicações), surge a necessidade de um ADC. Embora um ADC tradicional talvez não seja adequado para microsserviços, um ADC preparado para a nuvem será. Isso inclui um conjunto mais amplo de serviços que podem se beneficiar do balanceamento de carga e da segurança — serviços que pertencem claramente ao domínio de DevOps, e não de NetOps, como memcached.

Embora continue sendo uma plataforma, um ADC preparado para a nuvem oferece suporte aos requisitos de programabilidade, integração e formato necessários para fornecer os serviços de que aplicativos tradicionais e emergentes precisam, no ambiente em que precisam deles.

Há muitas semelhanças entre um ADC tradicional e um ADC preparado para a nuvem. Ambos continuam sendo plataformas capazes de viabilizar vários serviços com um modelo operacional comum. Ambos são programáveis, integram-se a outros sistemas de data center e de nuvem e oferecem flexibilidade em termos de capacidade de desempenho. No entanto, um ADC preparado para a nuvem vai além do tradicional: oferece suporte a ambos os cenários e, ao mesmo tempo, viabiliza o futuro dos negócios e das aplicações, bem como sua necessidade cada vez mais diversificada de integração e interoperabilidade com uma ampla variedade de infraestruturas e ambientes.

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