BLOG

O ADC pronto para a nuvem

Miniatura de Lori MacVittie
Lori MacVittie
Publicado em 05 de dezembro de 2016
adc pronto para a nuvem

Um controlador de entrega de aplicativo (ADC) pronto para a nuvem não é seu ADC tradicional. Disponível para implantação em hardware personalizado ou COTS, é uma solução de software escalável que oferece suporte à necessidade de entrega e implantação rápida, segura e disponível de aplicativos. Um ADC pronto para a nuvem permite uma abordagem moderna e em duas camadas para arquiteturas de data center, combinando estabilidade, segurança e escala tradicionais com recursos programáticos modernos, flexíveis, amigáveis à nuvem e ao DevOps.

Essa é uma bela descrição, mas o que isso significa?

Já escrevi antes sobre o que é preciso para ser considerado um proxy de aplicativo moderno e isso certamente é parte do que um ADC pronto para a nuvem exige, mas os ambientes exigentes de hoje precisam de mais do que apenas recursos técnicos, eles precisam de integração operacional e de ecossistema e da capacidade de oferecer suporte a arquiteturas de aplicativos modernas e emergentes.

E, honestamente, há muitos ADCs por aí que fariam as mesmas alegações de prontidão para a nuvem e suporte para arquiteturas de aplicativos tradicionais e emergentes, entre outras alegações. Então, hoje eu gostaria de me aprofundar no que torna um ADC pronto para a nuvem diferente de um ADC tradicional, antes de nos aprofundarmos no porquê de ele ser tão importante no mundo dos aplicativos de hoje.

Cinco Graus de Diferenciação

Existem basicamente cinco (seis se você quiser ser realmente pedante) maneiras diferentes nas quais um ADC pronto para a nuvem se diferencia de um ADC tradicional. E como o F5 praticamente definiu o que um ADC deveria ser muito antes de eu estar aqui, nós meio que entendemos o ADC melhor do que qualquer outra pessoa. Tanto o que eles precisavam ser quanto o que eles deveriam evoluir para continuar entregando aplicativos com a velocidade, segurança e estabilidade que os negócios precisam.

DESEMPENHO

Isso é óbvio, certo? Afinal, se você vai ficar na frente de aplicativos e representá-los, é melhor ser rápido (ou melhor ainda, mais rápido) do que os aplicativos que está entregando. Os ADCs tradicionais são entregues em formatos de aparelhos. Chassi, hardware, aparelhos. Mas os ADCs tradicionais ainda são limitados pelas CPUs naquele hardware personalizado com o qual eles precisam trabalhar. Os ADCs são plataformas, portanto tendem a se concentrar na velocidade geral, assim como as CPUs de uso geral se concentram no processamento geral. Mas eles quase sempre incluem uma variedade de opções de aceleração de hardware que precisam ser determinadas antes da implantação. Podemos estar loucos, mas achamos que um ADC pronto para a nuvem deve ser capaz de ir além dessa limitação, entendendo que um aplicativo pode precisar de um serviço mais do que outro, enquanto um aplicativo diferente pode precisar de algum outro serviço mais do que outro. Assim como a própria noção de redirecionamento da computação sob demanda que sustenta todo o conceito de computação em nuvem, as organizações que investem em hardware de qualquer tipo também devem ser capazes de redirecionar isso.

O motivo pelo qual isso é importante em serviços em camadas sobre a rede é que a descarga de tarefas comuns para hardware específico (FPGAs) significa que a CPU fica livre para fazer outras coisas, como inspeção de solicitação/resposta, modificação, limpeza, etc. Isso torna toda a "parada" no proxy mais rápida, o que se traduz em menor latência e usuários mais felizes.

É por isso que um ADC pronto para a nuvem pode quebrar barreiras, aproveitando o desempenho definido por software e permitindo que as organizações aumentem programaticamente o desempenho do ADC para certos tipos de processamento, como segurança. Isso significa que, se as necessidades da organização mudarem, o perfil de desempenho desse hardware poderá ser alterado junto, sob demanda. Isso é agilidade em hardware. Eu sei, paradoxal, certo? Mas isso faz parte de ser um ADC pronto para a nuvem: a capacidade de redirecionar hardware especializado para que os investimentos sejam protegidos e a necessidade de atualizações caras e em larga escala possa ser eliminada.

ícone de script do lado da rede

Programabilidade

Uma frustração de longa data que ouvi pessoalmente e repetidamente de clientes é a discórdia entre NetOps e DevOps quando se trata de recursos de script. O problema é que o ADC tradicional oferecia apenas os scripts mais básicos e em linguagens mais familiares ao NetOps, não ao DevOps. Agora, o DevOps estava disposto a aprender a tirar proveito do script no caminho de dados porque ele permitia uma variedade de roteamentos de solicitação/resposta mais ágeis, estratégias de dimensionamento e até mesmo serviços de segurança. Mas com o ADC tradicional instalado no upstream, na rede principal, a NetOps não estava disposta a deixar o DevOps implantar scripts que pudessem atrapalhar o fluxo de tráfego.

A disponibilidade de edições virtuais significava que os DevOps agora tinham acesso ao seu próprio ADC pessoal e privado na forma de uma máquina virtual, mas eles ainda eram forçados a aprender uma linguagem de script de rede. Isso não é bom. Um ADC pronto para a nuvem deve oferecer suporte tanto ao NetOps na rede principal quanto ao DevOps na rede de aplicativos, como na nuvem. E DevOps e desenvolvedores em particular preferem linguagens mais amigáveis ao desenvolvimento, como node.js. Não apenas porque eles conhecem a linguagem, mas porque já existe um rico repositório de bibliotecas (como o NPM ) e serviços para permitir uma integração mais rápida com uma infraestrutura amigável ao desenvolvimento. É por isso que um ADC pronto para a nuvem deve oferecer suporte a ambos.

segurança de aplicativos

 

Segurança de aplicações

 

Os ADCs tradicionais há muito fornecem segurança básica para aplicativos. Estar diante de um aplicativo, principalmente aplicativos da web, significa que eles geralmente eram (e ainda são) a primeira coisa no data center a reconhecer um ataque e fazer algo a respeito. A maior parte dessa segurança girava, compreensivelmente, em torno da segurança em nível de protocolo. Proteção contra inundação SYN, detecção de DDoS e outras opções de segurança básicas relacionadas a TCP e HTTP já fazem parte dos ADCs tradicionais há algum tempo.

Mas um ADC pronto para a nuvem deve ir além. Eles provavelmente serão um dos poucos "dispositivos" incluídos na arquitetura do aplicativo em si, para garantir a escala inevitável necessária aos aplicativos de hoje, então ter um foco semelhante na segurança de pilha completa faz sentido. Pelo menos é o que pensamos, principalmente porque isso promove o desempenho. Se você tiver que parar para um tipo de processamento, faz sentido fazer o máximo possível ao mesmo tempo. É mais eficiente e elimina a latência necessária para viajar de caixa em caixa. Se você já viajou longas distâncias com crianças, sabe do que estou falando. Há um banheiro no posto de gasolina. Você não quer parar novamente em um ponto de descanso cinco minutos depois, certo? A mesma coisa acontece com a segurança na rede. Faça o máximo que puder de uma só vez para eliminar despesas gerais que geralmente são fonte de frustração para clientes e para a empresa. O desempenho é essencial, e um ADC pronto para a nuvem deve fazer tudo o que puder para garantir experiências de aplicativo mais rápidas.

Isso pode significar oferecer novos modelos para gerenciar a crescente demanda (e, em alguns casos, a exigência) de suporte a comunicações seguras entre dispositivos móveis e aplicativos. Isso significa suporte ao Forward Secrecy (FS) e à criptografia que o permite. Isso significa habilitar novos modelos para descarregar o processamento computacionalmente caro de criptografia e descriptografia para o hardware projetado para lidar com isso, sem quebrar as arquiteturas necessárias para dar suporte a microsserviços e aplicativos emergentes. Um ADC pronto para a nuvem deve oferecer suporte a ambos, permitindo comunicações rápidas e seguras, ao mesmo tempo em que se adapta perfeitamente às arquiteturas e ambientes de nuvem atuais.

orquestração

Ecossistema de Parceiros e Automação

A economia de outras APIs é essencial para o sucesso da nuvem privada e para a vantagem competitiva proporcionada aos negócios pelos aumentos na automação e orquestração. Mas não importa o quão bom seja, sempre haverá uma variedade de serviços no data center de diferentes fornecedores, todos com diferentes integrações e modelos de objetos. Isso geralmente significa uma automação dolorosa orientada por API que exige conhecimento especializado em todos os componentes necessários. A realidade é que há dois níveis de integração necessários, um para orquestração e outro para automação (não, eles não são a mesma coisa) . Há os recursos de automação inerentes da plataforma, por meio de APIs e modelos, e há a integração nativa no ecossistema de parceiros, onde a orquestração reina suprema. Ambos são necessários para um ADC pronto para a nuvem. O primeiro garante automação por meio de produtos proprietários ou scripts e frameworks personalizados como Puppet e Chef, enquanto o último permite orquestração por meio de controladores cada vez mais importantes como OpenStack, VMware e Cisco.

Um ADC pronto para a nuvem deve integrar e oferecer orquestração nativamente por meio das estruturas e sistemas usados para fornecer uma solução de orquestração abrangente.

Não é preciso dizer mais de uma vez que um ADC pronto para a nuvem deve oferecer suporte a modelos de nuvem.

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

modelos de aplicativos

Modelo de aplicativo

Os ADCs tradicionais nasceram da necessidade de oferecer um conjunto robusto de serviços para aplicações tradicionais. Monólitos, se preferir. Os aplicativos atuais são cada vez mais distribuídos, diversos e diferentes de seus antecessores tradicionais, aproveitando uma variedade de arquiteturas, plataformas e modelos de implantação. Sejam contêineres ou máquinas virtuais, ambientes de nuvem ou semelhantes, os aplicativos ainda precisam de alguns desses serviços. E onde há necessidade de mais de um serviço ao mesmo tempo (como, digamos, balanceamento de carga e segurança de aplicativo), então você encontrará a necessidade de um ADC. Embora um ADC tradicional possa não atender aos requisitos para microsserviços, um ADC pronto para a nuvem atenderá. Isso inclui um conjunto mais amplo de serviços que podem se beneficiar do balanceamento de carga e da segurança, serviços que se enquadram diretamente no domínio do DevOps, não do NetOps, como o Memcached .

Ainda sendo uma plataforma, um ADC pronto para a nuvem oferece suporte aos requisitos de programação, integração e formato necessários para fornecer os serviços que aplicativos tradicionais e emergentes precisam, no ambiente em que eles precisam.

 

Há muita similaridade entre um ADC tradicional e um ADC pronto para a nuvem. Ambos ainda são plataformas, capazes de habilitar múltiplos serviços com um modelo operacional comum. Ambos são programáveis, integram-se a outros sistemas de data center e nuvem e oferecem flexibilidade em recursos de desempenho. Mas um ADC pronto para a nuvem vai além do tradicional, oferecendo suporte a ambos e, ao mesmo tempo, possibilitando o futuro dos negócios, dos aplicativos e sua necessidade cada vez mais diversificada de integração e interoperabilidade com uma ampla variedade de infraestrutura e ambientes.