Nuvem híbrida realizada: F5, Azure e Azure Stack

Hoje em dia, muitos departamentos de TI são pressionados por grupos de liderança a abandonar a natureza estática dos tradicionais data centers internos e adotar arquiteturas mais dinâmicas e centradas na nuvem, aumentando a agilidade, a flexibilidade e a escalabilidade, ao mesmo tempo em que reduzem os custos operacionais. E como as nuvens públicas e privadas têm seus prós e contras, cerca de 71%¹ das empresas implementam modelos híbridos para se beneficiar de mais vantagens, ao mesmo tempo em que anulam muitas das desvantagens. No entanto, quase todas essas organizações fazem isso empregando infraestrutura de nuvem e serviços de aplicativos não homogêneos, o que aumenta drasticamente a complexidade para as equipes multifuncionais encarregadas de arquitetar e manter essas implantações.

Vincular dois (ou mais) ambientes de nuvem distintos para fabricar uma nuvem híbrida não é apenas benéfico do ponto de vista de agilidade, flexibilidade e escalabilidade, mas também permite uma série de casos de uso especializados que seriam muito mais difíceis — ou impossíveis — de implementar. Provavelmente, os mais comuns são:

Estabelecer e manter um backup geograficamente redundante e altamente disponível de uma nuvem privada para evitar o tempo de inatividade de aplicativos essenciais é muito caro e provavelmente dobraria o investimento necessário para executar uma única nuvem privada. Você não só precisaria do dobro de hardware físico, como também precisaria de um data center separado, com energia, refrigeração e equipe próprias em um local geograficamente separado.

Como alternativa, ambientes de HA e DR podem ser hospedados na nuvem pública por uma fração do custo. Os dados do aplicativo são armazenados sempre que é feito backup da nuvem privada, enquanto os recursos reais do aplicativo e da rede permanecem inativos até serem necessários, ou seja, no caso de um desastre ou falha da nuvem privada. Se necessário, esses aplicativos e recursos são criados e operacionalizados usando os dados armazenados, garantindo a disponibilidade do aplicativo e a continuidade dos negócios.

Desenvolver um novo aplicativo em uma nuvem privada pode ser substancialmente mais caro do que na nuvem pública. É necessário um investimento inicial de capital para executar a carga de trabalho, sem garantia de que funcionará ou será adotado no mercado atual. Por essas razões, as empresas estão seguindo o mantra "falhe rápido, falhe barato" ao usar a capacidade sob demanda da nuvem pública para desenvolver, testar e executar novos aplicativos no modo de produção. Uma vez considerados operacionalmente sólidos ou amplamente adotados pelos usuários, os aplicativos podem ser migrados para a nuvem privada, que pode ser mais segura e operacionalmente mais barata a longo prazo. Como alternativa, eles poderiam permanecer na nuvem pública, implantados em um ambiente de longo prazo e mais econômico, usando instâncias reservadas mais baratas e similares.

Muitas vezes considerado o recurso de nuvem híbrida mais desejável, o cloud bursting é provavelmente o mais difícil de implementar, frequentemente se tornando a baleia branca de muitas estratégias de nuvem híbrida. Com o cloud bursting, um aplicativo é executado predominantemente na nuvem privada. Quando a demanda excede a capacidade, solicitações adicionais são redirecionadas para uma réplica exata em execução na nuvem pública em infraestrutura alugada. No entanto, esse é um estado temporário, projetado para lidar com picos de tráfego inesperados que duram curtos períodos de tempo. Quando períodos de tráfego mais alto se tornam constantes, as empresas podem aumentar a capacidade de sua nuvem privada.

Configurar um ambiente de nuvem híbrida para bursting de nuvem é inerentemente difícil e complexo. É necessário um relacionamento sinérgico entre os dois ambientes, bem como uma orquestração à prova de falhas para garantir que o redirecionamento aconteça de forma autônoma e perfeita, com pouco ou nenhum impacto na experiência do usuário final. A dificuldade é ainda maior para as equipes encarregadas da configuração e do gerenciamento quando a infraestrutura, os serviços e as ferramentas usadas para executar e dar suporte aos aplicativos são diferentes para cada ambiente.

Não deveria ser surpresa para você saber que nem todas as nuvens são iguais. Cada um tem sua própria infraestrutura exclusiva, serviços de rede e aplicativos, ferramentas para desenvolvedores, interface de usuário e diferenciação em relação a outros concorrentes na nuvem. Por exemplo, é muito mais fácil para usuários do Sharepoint, Exchange, SQL Server ou outras tecnologias da Microsoft migrarem para o Microsoft Azure do que para a AWS ou Google Cloud. Essas diferenças de plataforma e serviço levam a incompatibilidades entre nuvens e tornam a tarefa de desenvolver ambientes de nuvem híbrida incrivelmente desafiadora.

No entanto, a Microsoft fez um progresso considerável no suporte à criação de nuvem híbrida, oferecendo recursos e serviços sinônimos em ambientes de nuvem pública e privada por meio do Azure e do Azure Stack, respectivamente. O Azure Stack, que foi revelado recentemente, oferece aos usuários muitos dos recursos e benefícios da nuvem pública com o controle e a segurança de um data center interno.

Compararemos três modelos comuns de nuvem híbrida de alto nível para demonstrar como essa nova abordagem, quando combinada com os serviços de aplicativos avançados da F5, simplifica drasticamente o desenvolvimento e a operação da nuvem híbrida.

Modelo 1 – Plataformas de nuvem não homogêneas e serviços de aplicativos

Nosso primeiro exemplo é um ambiente de nuvem híbrida usando o Azure com serviços de aplicativos nativos do Azure para o aspecto de nuvem pública, enquanto aproveita o VMware com serviços de aplicativos F5 para o componente de nuvem privada, conforme mostrado na figura 1.

A nítida falta de consistência entre os ambientes torna este o modelo mais difícil de implementar e operar. Com o caso de uso de HA/DR discutido anteriormente, um aplicativo teria que ser configurado individualmente para ser executado de forma idêntica em cada nuvem. Dadas as diferenças em máquinas virtuais, APIs e recursos de rede subjacentes, é improvável que essa seja uma tarefa simples. Essas diferenças contribuem para reduzir a portabilidade geral do aplicativo devido à complexidade necessária para operacionalizar o aplicativo em cada nuvem, o que efetivamente dobra o trabalho necessário para atingir resultados semelhantes. Além disso, cada plataforma também tem sua própria interface de portal exclusiva e ferramentas para desenvolvedores/administradores, o que faz com que esse modelo rapidamente se torne proibitivamente complicado.

E isso considerando apenas as diferenças nas plataformas. Quando você adiciona o efeito de serviços de aplicativos diferentes, com interfaces, ferramentas de administração e requisitos de configuração distintos, a complexidade cresce exponencialmente. E a disfunção de gerenciamento não é o único problema; inconsistências de recursos impedem que os aplicativos sejam configurados com os mesmos serviços em cada nuvem, expondo você a riscos adicionais. Por exemplo, serviços de segurança diferentes levam a conjuntos de regras e políticas de firewall separados. Isso pode criar brechas de segurança, resultando em tempo de inatividade do aplicativo ou perda de dados do cliente como resultado de quaisquer ataques cibernéticos subsequentes.

Modelo 2 – Plataformas de nuvem não homogêneas com serviços de aplicativos homogêneos

Essa configuração é semelhante à do Modelo 1, mas com cada ambiente de nuvem suportado pelos serviços de aplicativos F5, conforme ilustrado na figura 2.

Com serviços de aplicativos consistentes, todos os serviços, configurações e políticas do F5 podem ser replicados em ambientes com gerenciamento de painel único, reduzindo a pressão sobre os administradores de sistema. Em vez de aprender e equilibrar dois conjuntos separados de recursos, interfaces e terminologia, um conjunto padronizado e rico em recursos de serviços pode ser implantado no ambiente de nuvem híbrida. E esses serviços são independentes da nuvem (ou seja, são executados de forma idêntica em todas as nuvens), eliminando os medos de dependência de fornecedores que podem estar associados ao uso de serviços nativos da nuvem. No entanto, este modelo não aborda os problemas associados à infraestrutura de plataforma díspare, que precisarão ser levados em consideração.

Modelo 3 – Plataformas de Nuvem Homogêneas e Serviços de Aplicação

Este modelo final vê melhorias incrementais adicionais; adotando a configuração descrita no Modelo 2 e substituindo a nuvem privada VMware pelo Microsoft Azure Stack, conforme ilustrado na figura 3.