Nuvem híbrida concretizada: F5, Azure e Azure Stack
Introdução
Hoje em dia, muitos departamentos de TI são pressionados pelas lideranças a abandonar a natureza estática dos data centers locais tradicionais e adotar arquiteturas mais dinâmicas e centradas na nuvem, aumentando a agilidade, a flexibilidade e a escalabilidade e, ao mesmo tempo, reduzindo os custos operacionais. Como as nuvens públicas e privadas têm suas próprias vantagens e desvantagens, cerca de 71%1 (https://www.f5.com/resources/white-papers/hybrid-cloud-realized-f5-azure-and-azure-stack#footnote01) das empresas implementam modelos híbridos para aproveitar mais vantagens e neutralizar muitas das desvantagens. No entanto, quase todas essas organizações fazem isso utilizando serviços de infraestrutura de nuvem e de aplicações não homogêneos, o que aumenta drasticamente a complexidade para as equipes multifuncionais responsáveis por projetar e manter essas implantações.
Principais casos de uso de nuvem híbrida
Conectar dois (ou mais) ambientes de nuvem distintos para criar uma nuvem híbrida não só traz benefícios em termos de agilidade, flexibilidade e escalabilidade, como também viabiliza uma série de casos de uso especializados que seriam muito mais difíceis — ou impossíveis — de implementar. Entre eles, os mais comuns são:
Alta disponibilidade (HA) e recuperação de desastres (DR)
Estabelecer e manter um backup de nuvem privada com alta disponibilidade e redundância geográfica para evitar a indisponibilidade de aplicações essenciais é muito caro e provavelmente dobraria o investimento necessário para operar uma única nuvem privada. Além de precisar do dobro de hardware físico, seria necessário um data center separado, com infraestrutura própria de energia e refrigeração, além de uma equipe dedicada, em uma localização geograficamente distinta.
Como alternativa, os ambientes de alta disponibilidade (HA) e recuperação de desastres (DR) podem ser hospedados na nuvem pública por uma fração do custo. Os dados das aplicações são armazenados sempre que é feito um backup a partir da nuvem privada, enquanto os recursos de aplicação e de rede permanecem inativos até que sejam necessários, por exemplo, em caso de desastre ou falha da nuvem privada. Se necessário, essas aplicações e esses recursos são ativados e colocados em operação usando os dados armazenados, garantindo a disponibilidade das aplicações e a continuidade dos negócios.
Desenvolvimento e testes de aplicações
Desenvolver uma nova aplicação em uma nuvem privada pode ser consideravelmente mais caro do que em uma nuvem pública. Isso exige um investimento inicial de capital para executar a carga de trabalho, sem qualquer garantia de que ela funcionará ou será adotada pelo mercado atual. Por esses motivos, as empresas estão seguindo o mantra “falhe rápido, falhe barato”, usando a capacidade sob demanda da nuvem pública para desenvolver, testar e executar novas aplicações em ambiente de produção. Depois que as aplicações forem consideradas operacionalmente confiáveis ou amplamente adotadas pelos usuários, elas poderão ser migradas para a nuvem privada, que pode ser mais segura e ter um custo operacional menor no longo prazo. Como alternativa, elas podem permanecer na nuvem pública, implantadas em um ambiente de longo prazo mais econômico, com o uso de instâncias reservadas mais baratas e recursos semelhantes.
Expansão para a nuvem
Frequentemente considerado o recurso mais desejável da nuvem híbrida, o cloud bursting é provavelmente o mais difícil de implementar na prática, tornando-se muitas vezes o grande objetivo inalcançável de diversas estratégias de nuvem híbrida. Com o cloud bursting, uma aplicação é executada predominantemente na nuvem privada. Quando a demanda excede a capacidade, as solicitações adicionais são redirecionadas para uma réplica exata executada na nuvem pública, em uma infraestrutura alugada. No entanto, esse é um estado temporário, projetado para lidar com picos inesperados de tráfego que duram pouco tempo. Quando os períodos de tráfego mais intenso se tornam contínuos, as empresas podem ampliar a capacidade de sua nuvem privada.
Configurar um ambiente de nuvem híbrida para cloud bursting é algo inerentemente difícil e complexo. Isso exige uma relação sinérgica entre os dois ambientes, além de uma orquestração à prova de falhas para garantir que o redirecionamento ocorra de forma autônoma e transparente, com pouco ou nenhum impacto na experiência dos usuários finais. A dificuldade aumenta ainda mais para as equipes responsáveis pela configuração e pelo gerenciamento quando a infraestrutura, os serviços e as ferramentas usados para executar e dar suporte às aplicações são diferentes em cada ambiente.
Homogeneidade: a chave para o sucesso da nuvem híbrida
Não é de surpreender que nem todas as nuvens sejam iguais. Cada uma tem sua própria infraestrutura, serviços de rede e de aplicativos, ferramentas de desenvolvimento e interface do usuário, além de diferenciais em relação às demais concorrentes do mercado de nuvem. Por exemplo, é muito mais fácil para os usuários do SharePoint, Exchange, SQL Server ou de outras tecnologias da Microsoft migrarem para o Microsoft Azure do que para a AWS ou o Google Cloud. Essas diferenças entre plataformas e serviços geram incompatibilidades entre as nuvens e tornam extremamente desafiadora a tarefa de desenvolver ambientes de nuvem híbrida.
No entanto, a Microsoft fez avanços consideráveis no suporte à criação de nuvens híbridas ao oferecer recursos e serviços equivalentes em ambientes de nuvem pública e privada por meio do Azure e do Azure Stack, respectivamente. O Azure Stack, lançado há pouco tempo, oferece aos usuários muitos dos recursos e benefícios da nuvem pública, aliados ao controle e à segurança de um data center interno.
Compararemos três modelos comuns de nuvem híbrida em alto nível para demonstrar como essa nova abordagem, quando combinada com os serviços avançados de aplicativos da F5, simplifica drasticamente o desenvolvimento e a operação da nuvem híbrida.
Modelo 1 – Plataformas de nuvem e serviços de aplicações não homogêneos
Nosso primeiro exemplo é um ambiente de nuvem híbrida que utiliza o Azure com serviços de aplicativos nativos do Azure na parte de nuvem pública, enquanto emprega o VMware com serviços de aplicativos da F5 no componente de nuvem privada, conforme mostrado na figura 1.
A evidente falta de consistência entre os ambientes torna este o modelo mais difícil de implementar e operar. No caso de uso de HA/DR discutido anteriormente, seria necessário configurar individualmente uma aplicação para que ela fosse executada de forma idêntica em cada nuvem. Considerando as diferenças entre máquinas virtuais, APIs e recursos de rede subjacentes, é improvável que essa seja uma tarefa simples. Essas diferenças reduzem a portabilidade geral da aplicação devido à complexa infraestrutura necessária para colocá-la em operação em cada nuvem — o que, na prática, dobra o trabalho necessário para alcançar resultados semelhantes. Além disso, como cada plataforma também tem sua própria interface de portal e suas próprias ferramentas para desenvolvedores e administradores, esse modelo rapidamente se torna excessivamente complexo.
E isso considerando apenas as diferenças entre as plataformas. Quando se acrescenta o impacto de serviços de aplicação distintos, com interfaces, ferramentas de administração e requisitos de configuração diferentes, a complexidade aumenta exponencialmente. E as dificuldades de gerenciamento não são o único problema: as inconsistências de recursos impedem que as aplicações sejam configuradas com os mesmos serviços em cada nuvem, expondo você a riscos adicionais. Por exemplo, serviços de segurança distintos resultam em conjuntos de regras de firewall e políticas separados. Isso pode criar brechas de segurança, causando indisponibilidade da aplicação ou perda de dados de clientes em decorrência de eventuais ataques cibernéticos.
Modelo 2 – Plataformas de nuvem não homogêneas com serviços de aplicação homogêneos
Essa configuração é semelhante à do Modelo 1, mas cada ambiente de nuvem conta com o suporte dos serviços de aplicação da F5, conforme ilustrado na figura 2.
Com serviços de aplicação consistentes, todos os serviços, configurações e políticas da F5 podem ser replicados entre ambientes e gerenciados por meio de um painel único, reduzindo a sobrecarga dos administradores de sistemas. Em vez de aprender e conciliar dois conjuntos distintos de recursos, interfaces e terminologias, é possível implantar um único conjunto padronizado e completo de serviços em todo o ambiente de nuvem híbrida. Além disso, esses serviços são independentes de nuvem (ou seja, funcionam de forma idêntica em todas as nuvens), eliminando o receio de dependência de fornecedor que pode estar associado ao uso de serviços nativos da nuvem. No entanto, esse modelo não resolve os problemas relacionados às diferenças na infraestrutura das plataformas, que precisarão ser levados em consideração.
Modelo 3 – Plataformas de nuvem e serviços de aplicações homogêneos
Este modelo final apresenta mais uma melhoria incremental, adotando a configuração descrita no Modelo 2 e substituindo a nuvem privada da VMware pelo Microsoft Azure Stack, conforme ilustrado na figura 3.
Para quem não conhece o Azure Stack, essa plataforma de nuvem foi projetada para ser uma extensão (ou apenas mais uma região) do Azure na nuvem privada, com serviços, ferramentas e infraestrutura virtual idênticos. Seu valor está na capacidade de transferir facilmente cargas de trabalho entre ambientes de nuvem híbrida sem a necessidade de refatorar as aplicações. Além disso, a consistência das ferramentas do Azure e da interface do portal reduz a complexidade do gerenciamento. Como proprietário de uma aplicação, você pode desenvolvê-la e testá-la no Azure e, em seguida, transferi-la de forma rápida e transparente para o Azure Stack para implantação em produção (ou vice-versa), oferecendo suporte a ambas as instâncias com os mesmos serviços de aplicações F5 de nível empresarial.
Em comparação com o Modelo 1, este modelo de nuvem híbrida combina os benefícios de serviços de aplicação e infraestrutura de nuvem consistentes, ao mesmo tempo que reduz pela metade o número de variáveis do sistema, de quatro para duas, aumentando significativamente a portabilidade das aplicações e reduzindo a sobrecarga da gestão de TI. A unificação das plataformas e dos serviços de aplicação permite que os operadores de rede e a gestão de TI vejam sua arquitetura de nuvem híbrida como uma entidade única e homogênea, em vez de dois monólitos distintos.
A nuvem verdadeiramente híbrida: F5 para Azure e Azure Stack
Executada de forma idêntica em ambas as plataformas, a edição virtual (VE) do BIG-IP da F5 aumenta a equivalência entre as arquiteturas do Azure e do Azure Stack por meio da replicação dos serviços de aplicativos de suporte. Os desenvolvedores podem não apenas desenvolver um aplicativo em um ambiente e transferi-lo para outro, mas também espelhar pilhas completas prontas para produção, incluindo as mesmas configurações, políticas e serviços de aplicativos do BIG-IP. Isso elimina a necessidade de inúmeras horas de refatoração e testes de aplicativos e permite que os desenvolvedores se concentrem no que fazem de melhor: escrever código.
A segurança dos aplicativos e de seus dados costuma ser uma preocupação para os desenvolvedores que migram aplicativos para a nuvem pública — mas não precisa ser assim. Um desenvolvedor pode criar um aplicativo em seu ambiente do Azure Stack, enquanto um arquiteto de segurança define as configurações necessárias no firewall de aplicativos Web (WAF) da F5. Toda a pilha pode ser replicada no Azure com a certeza de que o aplicativo estará protegido pelo mesmo WAF líder do setor. Com políticas e conjuntos de regras idênticos, não haverá brechas de segurança nem vulnerabilidades que poderiam surgir com o uso de WAFs distintos.
E como o Azure Stack é compatível com o Azure Resource Manager (ARM), a ampla seleção de modelos ARM da F5 pode ser usada para automatizar a implantação e a configuração de instâncias do BIG-IP VE em ambos os ambientes, reduzindo significativamente o tempo de inicialização e aumentando a eficiência da nuvem híbrida. Em última análise, todo o trabalho realizado pela F5 para alcançar uma integração tão estreita com o Azure agora beneficia tanto os clientes do Azure quanto os clientes do Azure Stack.
Conclusão
Há muitos motivos pelos quais uma organização pode optar por investir em uma estratégia de nuvem híbrida, assim como há diversas maneiras de implementá-la. Ao diversificar e utilizar várias plataformas de nuvem distintas e diferentes provedores de serviços de aplicações, as empresas tornam a implementação e a operação de uma arquitetura de nuvem híbrida exponencialmente mais desafiadoras.
Ao padronizar os serviços avançados de aplicações da F5 em todos os ambientes de nuvem e, ao mesmo tempo, aproveitar a natureza homogênea das plataformas de nuvem Azure e Azure Stack da Microsoft, as organizações de TI podem criar uma arquitetura verdadeiramente híbrida, com total portabilidade das aplicações entre os ecossistemas. Oferecer suporte às aplicações com os mesmos serviços de gerenciamento de tráfego e segurança do BIG-IP permite que as equipes de rede e segurança otimizem a disponibilidade das aplicações para os usuários finais, protegendo-as e preservando seus dados com recursos e políticas de segurança consistentes.
E, neste capítulo ainda relativamente inicial da história da computação em nuvem, muitas organizações de TI estão sob pressão para tomar decisões difíceis sobre sua estratégia de nuvem de longo prazo — se ela deve ser totalmente baseada na nuvem pública, totalmente na nuvem privada ou em uma combinação de ambas. Os serviços de aplicações da F5 para Azure e Azure Stack reduzem os impactos dessa decisão ao criar uma solução holística, na qual todo um portfólio de aplicações pode ser migrado entre ambientes de nuvem a qualquer momento, adaptando-se às mudanças nos requisitos de negócios.
NOTA DE RODAPÉ:
1 Relatório RightScale sobre o Estado da Nuvem de 2018
PUBLICADO EM 09 DE MAIO DE 2018