Um dos benefícios da nuvem mencionados com frequência — seja ela privada ou pública, local ou externa — é a velocidade. Velocidade para provisionar, para escalar e, por fim, para disponibilizar um aplicativo aos usuários que desejam ou precisam de suas funcionalidades.
Para alcançar essa velocidade, grande parte da nuvem é padronizada. Desde os primórdios da automação das linhas de montagem, a padronização sempre foi a chave de ouro para obter resultados mais rápidos. Isso continua sendo verdade nos ambientes de nuvem. Embora a Amazon não seja padronizada no sentido de que suas APIs sejam intercambiáveis com as do Azure, do Google ou até mesmo do OpenStack, há padronização em todos os seus diversos serviços, o que significa que todas as aplicações implantadas sobre sua infraestrutura compartilham grande parte dos procedimentos operacionais cotidianos.
O mesmo se aplica ao OpenStack, que oferece uma implantação padrão com serviços padronizados, mas permite criar ambientes personalizados por meio de sua arquitetura de plug-ins. Isso significa que você pode combinar balanceadores de carga, firewalls de aplicações web e recursos de computação para atender às suas necessidades específicas.
No entanto, o que o OpenStack não faz é levar essa abordagem personalizada além do básico sem código adicional. Por exemplo, você pode integrar outro balanceador de carga, mas fica limitado aos algoritmos e recursos disponíveis por meio do OpenStack. Portanto, se um balanceador de carga tiver recursos avançados — como programabilidade do caminho de dados (que, segundo nossas pesquisas, é bastante importante, pelo menos para os profissionais de NetOps), terminação SSL ou suporte a perfis TCP distintos para o lado do usuário e o lado do servidor —, não será possível usar a API do OpenStack para ativá-los ou desativá-los. Isso ocorre porque eles não são recursos “padrão” em todos os balanceadores de carga que podem ser integrados.
É justo. Mas o que não é justo é obrigar 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 código aberto mais uma vez vem ao resgate e comprova seu valor: 90% dos participantes da pesquisa State of Open Source citam a “inovação” como um dos aspectos aprimorados pelo código aberto.
Para fornecer acesso aos recursos avançados disponíveis para quem utiliza o F5 BIG-IP para balanceamento de carga e entrega segura de aplicações — sem comprometer o OpenStack —, implementamos a capacidade de definir e incluir esses recursos de forma integrada em uma implementação do OpenStack.
A Definição de Serviço Aprimorada (ESD) do F5 OpenStack LBaaSv2 oferece um mecanismo simples, baseado em JSON, para especificar o provisionamento de perfis avançados no F5 BIG-IP em um ambiente OpenStack. Com as ESDs, você pode implantar balanceadores de carga do OpenStack personalizados para aplicações específicas.
Em resumo, uma ESD é um arquivo no formato JSON padrão, com pares de chave-valor que descrevem perfis, políticas ou iRules que você deseja aplicar a aplicações específicas.
Por exemplo, o JSON à esquerda instrui o BIG-IP a aplicar uma iRule chamada “cve-2015-1635” ao servidor virtual (o aplicativo) chamado “app_dot_net”.
É isso. Esse pequeno e simples trecho de código permite proteger um aplicativo contra uma CVE real usando um pouco da magia dos scripts de caminho de dados e da inovação do código aberto.
Perfis e políticas também podem ser aplicados da mesma forma 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ê também pode estendê-lo, se quiser. No entanto, a possibilidade de aproveitar os ESDs oferece a mesma extensibilidade que ter acesso ao código para fazer isso por conta própria.
Mas, afinal, é código aberto, então vale o que funcionar para você e, mais importante, entregar seus aplicativos.
Você pode saber mais sobre ESDs e baixar o driver F5 OpenStack LBaaSv2 para BIG-IP no GitHub aqui:
Sobre o autor
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 VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...