Um dos benefícios frequentemente mencionados da nuvem – privada ou pública, local ou externa – é a velocidade. Velocidade de provisionamento, velocidade de escala, velocidade para finalmente entregar um aplicativo aos usuários que desejam ou exigem sua funcionalidade.
Para obter essa velocidade, grande parte da nuvem é padronizada. A padronização sempre foi, desde os primeiros dias da automação de linhas de montagem, a chave de ouro para alcançar resultados mais rápidos. Isso continua sendo verdade em ambientes de nuvem. Embora a Amazon não seja padronizada no sentido de que suas APIs sejam intercambiáveis com as do Azure, Google ou mesmo OpenStack, ela é padronizada em todos os seus vários serviços, o que significa que todos os aplicativos implantados em sua infraestrutura compartilham muito de seus procedimentos operacionais diários.
O mesmo vale para o OpenStack, que tem uma implantação padrão com serviços padrão, mas permite ambientes personalizados por meio de sua arquitetura de plug-in. Isso significa que você pode misturar e combinar balanceadores de carga e firewalls de aplicativos da web e calcular para atender às suas necessidades específicas.
O que o OpenStack não faz, no entanto, é adotar essa abordagem personalizada além do básico, sem código adicional. Por exemplo, você pode conectar um balanceador de carga diferente, mas estará limitado aos algoritmos e recursos disponíveis pelo OpenStack. Então, se um balanceador de carga tiver recursos avançados – digamos, programabilidade de caminho de dados (que nossas pesquisas nos dizem ser muito importante para o pessoal do NetOps, pelo menos) ou terminação SSL ou suporte para perfis TCP distintos do lado do usuário e do lado do servidor – você não pode realmente usar a API do OpenStack para ligá-los e desligá-los. Porque eles não são recursos “padrão” em todos os balanceadores de carga que você pode conectar.
Isso é justo. Mas o que não é justo é forçar você a escolher entre esses recursos avançados que tornam os aplicativos mais rápidos e seguros e os benefícios de uma plataforma de nuvem padronizada como o OpenStack.
É aí que o Open Source mais uma vez vem ao resgate e prova com 90% dos entrevistados na pesquisa State of Open Source citando “inovação” como uma das coisas que o open source melhora.
Para fornecer acesso a esses recursos avançados disponíveis para aqueles que dependem do F5 BIG-IP para balanceamento de carga e entrega segura de aplicativos – sem interromper o OpenStack – implementamos a capacidade de definir e incluir perfeitamente esses recursos em uma implementação do OpenStack.
A Definição de Serviço Aprimorada (ESD) do F5 OpenStack LBaaSv2 fornece um mecanismo simples baseado em JSON para especificar o provisionamento de perfis avançados no F5 BIG-IP em um ambiente OpenStack. Com ESDs, você pode implantar balanceadores de carga OpenStack personalizados para aplicativos específicos.
Em poucas palavras, um ESD é um arquivo em formato JSON padrão com pares de chave-valor descrevendo perfis, políticas ou iRules que você deseja aplicar a aplicativos específicos.
Por exemplo, o JSON à esquerda informa ao BIG-IP para aplicar uma iRule chamada “ cve-2015-1635 ” ao servidor virtual (o aplicativo) chamado “app_dot_net”.
É isso. Este pequeno e simples trecho habilita um aplicativo com proteção contra um CVE real usando um pouco de mágica de script de caminho de dados e um pouco de inovação de código aberto.
Perfis e políticas também podem ser aplicados da mesma maneira usando as tags apropriadas, todas documentadas aqui .
O driver F5 OpenStack LBaaSv2 para BIG-IP é de código aberto e está disponível no Github. Você pode estender isso também, se quiser. Embora a capacidade de aproveitar ESDs ofereça a mesma extensibilidade de ter acesso ao código para fazer isso você mesmo.
Mas ei, é de código aberto, então qualquer coisa que acione seu gatilho e, mais importante, entregue seus aplicativos.
Você pode ler mais sobre ESDs e obter o driver F5 OpenStack LBaaSv2 para BIG-IP no github aqui: