Destaque do código aberto: F5 Infraestrutura como código e gerenciabilidade multi-nuvem
Você deve ter notado que um ponto importante no mantra da multinuvem é a capacidade de gerenciamento. Isso ocorre porque a tarefa de dimensionar, proteger e entregar aplicativos aos usuários exige um determinado conjunto de serviços: balanceadores de carga, computação, armazenamento e segurança de aplicativos. E embora a nuvem possa (e de fato) facilitar muito o processo de provisionamento desses serviços, ela o faz em detrimento das operações. Infelizmente, isso move a complexidade para outro lugar.
Se você é quem fornece esses serviços, tudo bem. Mas se você é quem tem que configurar, ajustar e gerenciar serviços, não é tão legal.
Porque a complexidade dificulta a gestão. Não há duas nuvens iguais (em termos de APIs e serviços) e isso geralmente significa dois modelos operacionais completamente separados com os quais as pessoas agora precisam lidar.
Portanto, a capacidade de gerenciamento é uma parte importante para o sucesso da multinuvem.
Uma das maneiras pelas quais as organizações podem fazer isso é adotar construções que simplifiquem as implantações. Elas estão cada vez mais na forma de algum tipo de modelo: OpenStack HEAT, AWS Cloud Formation e Azure ARM vêm à mente. Esses modelos codificam a maior parte de uma implantação de BIG-IP em termos da configuração específica que precisa estar em vigor para gerar o valor real de um BIG-IP – seus serviços.
Os modelos são um dos melhores exemplos de infraestrutura como código (IAC). Isso ocorre porque eles podem ser tratados exatamente como artefatos de código. Eles podem ser versionados, ramificados, mesclados, recuperados, clonados e, finalmente, implantados.
Este modelo combina bem com a visão de nuvem orientada ao DevOps e gerenciamento por meio de APIs e linguagens de script. Afinal, se o DevOps puder estender sua influência ao NetOps e, por sua vez, puder implementar serviços rapidamente usando uma abordagem IAC, todos ficarão felizes. É exatamente o que o médico receitou, considerando que a falta de tais serviços da NetOps influencia significativamente as decisões da DevOps de contornar a TI quando se trata de nuvem.
Dar suporte à capacidade de gerenciamento de várias nuvens é exatamente o que nós (a empresa que somos agora) imaginamos quando começamos a desenvolver modelos para OpenStack, AWS e Azure. Permitir uma abordagem IAC para fornecer maior agilidade e velocidade é o motivo pelo qual esses modelos estão disponíveis gratuitamente no GitHub.
Porque nossas implantações de laboratório não são suas implantações e nem são as daquele outro cara (na fileira atrás de você, lendo por cima do seu ombro). As implantações compartilham um conjunto comum de características, mas todos os aplicativos têm necessidades específicas que não podem ser atendidas com a mesma configuração de serviço mercantilizada. O balanceamento de carga round robin pode ser bom o suficiente para aplicativos sem estado e baseados em microsserviços, mas pode ser terrivelmente ineficiente (para não mencionar caro) para outras arquiteturas de aplicativos, especialmente em ambientes de nuvem. Você precisa de liberdade para adaptar e otimizar o desempenho do aplicativo e garantir a segurança dos dados e das interações do usuário.
Você precisa ser capaz de extrair, clonar e confirmar esses artefatos em seus próprios repositórios para poder colher os benefícios de uma abordagem NetOps que inclua IAC para implantar o máximo possível de sua base de serviços, em tantos ambientes de nuvem quanto possível.
Então, puxe, clone, confirme e implante de acordo com sua programação, seja três vezes por dia ou três vezes por trimestre. É de código aberto e está sempre aberto para acesso.