As organizações que consideram mover aplicativos corporativos para a nuvem pública devem garantir que também movam os serviços de entrega de aplicativos dos quais seus aplicativos dependem para o data center. Além disso, a migração para a nuvem representa uma oportunidade de organizar e racionalizar a segurança e o acesso, obter visibilidade do tráfego de aplicativos baseados na nuvem e arquitetar um forte plano de recuperação de desastres.

Para muitas organizações, mover aplicativos empresariais para a nuvem pública pode ser uma proposta muito atraente. Isso permite que eles descartem os custos fixos e os ativos envolvidos na execução de infraestrutura de TI em larga escala, incluindo data centers caros repletos de equipamentos de diferentes gerações e níveis de suporte. Enquanto esses servidores executam a empresa, eles também consomem energia, geram calor e exigem contratos de suporte caros. Gerenciar o ciclo de vida, a manutenção e o alojamento físico da infraestrutura de TI exige habilidades, tempo e orçamento que podem prejudicar a missão geral das organizações de TI: fornecer os aplicativos que executam os negócios.

Livrar-se dessa dor de cabeça operacional e do dreno financeiro em troca de um novo mundo onde um servidor ou aplicativo antigo pode ser desativado com uma simples chamada de API geralmente faz sentido financeiro e operacional. Se você não precisa mais gerenciar a infraestrutura básica que executa sua TI, pode se concentrar mais na segurança, no desempenho e na disponibilidade dos aplicativos que representam o valor real que a TI traz para a empresa.

Mas antes de chegar a esse nirvana de infraestrutura virtualizada e livre de manutenção, você terá que descobrir a melhor maneira de mover seus aplicativos para seu novo lar. Migrar um aplicativo para a nuvem pública envolve algumas escolhas. Você pode reestruturar completamente o aplicativo para um ambiente de nuvem, o que pode resultar em uma experiência de usuário elegante e otimizada, mas muitas vezes pode ser um processo demorado e trabalhoso. Como alternativa, você pode simplesmente pegar os aplicativos em execução no seu data center e colocá-los em uma nuvem pública sem fazer grandes alterações no design ou na plataforma.

Há uma série de boas razões para explorar este modelo de "elevação e mudança": Estima-se que seja cerca de 10x mais barato,¹ quase sempre é muito mais rápido e, em alguns casos, simplesmente não vale a pena reescrever um aplicativo com vida útil limitada. Mas se você pretende ter uma migração "lift and shift" bem-sucedida, há algumas regras que você deve seguir — e uma que você precisará quebrar.

Começaremos com aquele que deve ser quebrado. O conceito de tratar servidores como gado é frequentemente visto como intrínseco às arquiteturas de nuvem. Se uma instância do servidor estiver funcionando incorretamente, não perca tempo consertando-a: basta eliminá-la e reimplantá-la. Não atualize sistemas operacionais ou software; apenas implante novas instâncias e encerre as antigas. Este é um conselho sólido. Mas isso pode sair pela culatra se você estiver tentando mover um aplicativo que nasceu e cresceu no luxo do data center para o mundo frio e duro da nuvem pública.

A maioria dos aplicativos corporativos não foi projetada com arquiteturas e metodologias de nuvem em mente. Eles mantêm o estado localmente, demoram para ficar online após a inicialização do servidor subjacente e desligamentos repentinos provavelmente resultarão em dados inconsistentes. Você precisa tratá-los como animais de estimação mimados que eles são, não como gado.

Aplicativos corporativos transferidos para ambientes de nuvem precisam de muitos dos mesmos cuidados, gerenciamento e serviços de entrega de aplicativos (segurança, disponibilidade e desempenho) que recebem no data center. Mesmo os serviços básicos de balanceamento de carga que esses aplicativos exigem serão mais complexos do que aqueles necessários para um aplicativo que foi projetado e criado na nuvem. Se você quer que seu aplicativo prospere na nuvem, você precisa mover sua infraestrutura de suporte junto com ele. Felizmente, a maioria dos componentes de infraestrutura agora está disponível na nuvem pública de sua escolha, e você pode reutilizar seu conhecimento organizacional, habilidades e até mesmo políticas na nuvem.

A evolução da maioria das TI empresariais segue um caminho que lembra um rack de fiação de painel de conexão. Você sabe qual é. Começa lindo, bem projetado e perfeitamente executado. (Dê uma olhada em reddit.com/r/cableporn para algumas configurações realmente inspiradoras.) No entanto, em um ano, as necessidades de tempo e urgência resultaram em um atalho aqui e no uso da cor errada ali ("vermelho é para a DMZ, droga!"). Em três curtos anos, o gabinete se degenerou em um nó górdio de cabeamento Ethernet multicolorido e sem etiqueta que só precisa ser arrancado e reconfigurado.

Migrar para a nuvem é sua chance de se livrar daquele painel de patch confuso e retomar o controle da segurança e do gerenciamento de acesso. Embora você precise mover alguns dos seus serviços de infraestrutura junto com o aplicativo, você deve aproveitar esta oportunidade para racionalizar, visualizar e organizar sua estratégia de acesso ao aplicativo e à rede.

Provavelmente, o controle mais importante que você pode implementar é o gerenciamento da identidade do usuário em seus ambientes de nuvem. À medida que você move alguns aplicativos para a nuvem, descontinua alguns aplicativos em favor de ofertas de Software como Serviço (SaaS) ou reescreve alguns aplicativos completamente, você precisará tomar várias decisões importantes sobre o gerenciamento de identidade do usuário.

Executar vários serviços de identidade pode ser oneroso, arriscado e ineficiente, além de poder gerar parte da complexidade que você deveria tentar eliminar. O gerenciamento de identidade precisa ser centralizado, mas o acesso deve ser federado em todos os locais necessários. A tecnologia que se integra ao seu serviço de identidade (geralmente o Microsoft Active Directory) e o estende para serviços de nuvem e SaaS usando protocolos como SAML e OAuth permite que os aplicativos autentiquem usuários com uma única fonte, em vez de depender de identidade local.

Mas assim como os aplicativos se tornaram mais dispersos, os usuários também se tornaram. Adicionar controles que identifiquem a localização e os dispositivos de um usuário, combinados com opções de autenticação de dois fatores e senhas de uso único, pode fornecer defesa contra engenharia social e tentativas semelhantes de comprometer a segurança das informações da sua organização.

Ambientes de nuvem abstraem diversas camadas de infraestrutura de sua preocupação direta. Isso é bom, porque agora você não precisa fazer manutenção e suporte a uma infraestrutura física. No entanto, essa terceirização de responsabilidade também acarreta uma cessão de controle direto.

Uma das coisas que você precisa fazer para neutralizar isso é monitorar o desempenho do aplicativo com mais cuidado. Adicionar um melhor monitoramento que forneça informações relevantes e acionáveis pode facilitar a solução de problemas e o planejamento de capacidade.

Outro benefício pode ser a eliminação de algumas preocupações dentro do negócio. Dúvidas sobre segurança e desempenho na nuvem vêm, em parte, dos aspectos multilocatários e de conexão pública da nuvem pública, mas também surgem da perda de controle percebida. Adicionar um melhor monitoramento de aplicativos e comportamento corporativo pode ajudar significativamente a promover essa migração e remover barreiras emocionais à adoção da nuvem.

Recuperação de desastres e continuidade de negócios (DR/BC) são pilares de uma boa infraestrutura de data center e design de aplicativos. Usar uma nuvem pública não remove sua responsabilidade de manter os aplicativos funcionando e seguros. No entanto, isso reduz a barreira de entrada para serviços DR/BC.

Antes da disponibilidade dos serviços de nuvem pública, a criação de um local físico de recuperação de desastres poderia envolver custos e prazos de entrega significativos. Agora, você pode acessar infraestrutura em outro continente de um fornecedor diferente usando uma tecnologia subjacente diferente em questão de minutos. Mas, embora a infraestrutura possa estar muito mais prontamente disponível, a criação de um aplicativo de alta disponibilidade ainda requer planejamento e configuração significativos.

Embora haja ampla documentação dedicada ao tópico de recuperação de desastres e infraestruturas de nuvem, uma boa estrutura para planejamento e design para DR/BC pode ser reduzida a algumas decisões e preocupações importantes.

Primeiro, você precisa pensar sobre risco e retorno sobre o investimento (ROI). A solução definitiva para várias regiões e vários fornecedores valerá o tempo e o investimento? Embora os serviços de nuvem possam reduzir o custo de aquisição, os custos operacionais de manutenção de serviços robustos de DR/BC ainda existirão.

Em segundo lugar, você precisa pensar em como irá armazenar e distribuir dados transacionais e mantê-los consistentes. Este é um problema bem compreendido, mas talvez seja a parte mais difícil de criar aplicativos geograficamente dispersos e altamente disponíveis. Muitas soluções exigem conexões de alta largura de banda e baixa latência entre locais ou designs mais esotéricos, como um modelo de consistência eventual que os aplicativos corporativos raramente adotam. Criar conectividade de baixa latência entre diferentes provedores de nuvem não está ao alcance da maioria das empresas, mas algumas opções estão se tornando disponíveis.

O terceiro desafio principal é gerenciar o acesso aos seus aplicativos. Para a maioria dos projetos ativos-ativos ou ativos-DR, usar DNS para direcionar o tráfego para o data center ideal com base na disponibilidade, proximidade ou desempenho representa o melhor equilíbrio entre simplicidade e funcionalidade. Isso é especialmente verdadeiro quando você considera um modelo de multinuvem no qual usa diferentes fornecedores de nuvem para seus aplicativos. Usar protocolos de rede como BGP também pode ser uma opção, mas isso geralmente adiciona complexidade e algum risco. Outra opção pode ser simplesmente balancear a carga ou alternar o tráfego de rede entre nuvens usando equipamentos ou serviços colocados em locais fora da nuvem, mas próximos a ela, o que nos leva à nossa regra final.

A maioria das organizações de médio a grande porte que migram aplicativos empresariais para a nuvem desejarão criar acesso privado seguro em sua infraestrutura de nuvem. Embora executar uma solução VPN pela Internet pública possa ser apropriado para alguns, muitas organizações usarão uma conexão mais direta e dedicada ao provedor de nuvem. Esses links dedicados fornecidos por provedores de serviços oferecem privacidade, largura de banda garantida e menor latência do que as conexões públicas de Internet, mas têm um preço.

E se você precisar de conexões resilientes com mais de uma nuvem, será necessário provisionar vários links. Ou o que acontece se você precisar conectar sua nuvem a alguns componentes de infraestrutura, mas seus data centers existentes estiverem geográfica ou logicamente muito distantes dos pontos de peering da rede de nuvem?

Cada vez mais, as organizações estão considerando colocar equipamentos em ambientes conectados à nuvem (comumente chamados de trocas de nuvem) que oferecem conexões de alta velocidade para vários provedores de nuvem. Isso permite que você hospede alguns de seus ativos de TI extremamente próximos de sua infraestrutura virtual de nuvem, o que lhe dá conexões privadas e de baixa latência entre aplicativos em execução na nuvem e componentes de infraestrutura, como dispositivos de armazenamento ou segurança, alojados no centro de colocation. Além disso, esse arranjo permite que você aproveite o equipamento de TI existente e estenda os controles de rede e segurança para a infraestrutura de nuvem.

Por fim, a colocalização em um ambiente de troca de nuvem permite que você coloque controles no nexo entre seu data center corporativo, suas infraestruturas de nuvem e a Internet pública. Você pode estender ou criar as políticas de segurança que sua empresa exige e obter maior controle e visibilidade dos fluxos de dados de aplicativos, melhorando sua postura geral de segurança e ajudando a racionalizar e padronizar os serviços de acesso e segurança.

Transferir e migrar aplicativos corporativos para uma nuvem pública pode permitir que as organizações economizem dinheiro, aumentem a flexibilidade e migrem rapidamente para um ambiente de nuvem. No entanto, reconhecer que os aplicativos corporativos ainda precisam de uma infraestrutura envolvente é essencial para uma migração bem-sucedida.

Garantir que os serviços dos quais seus aplicativos dependem para segurança, desempenho e disponibilidade estejam presentes na nuvem manterá seus aplicativos empresariais tradicionais em execução e seus usuários satisfeitos. O monitoramento integrado permitirá que você identifique áreas problemáticas rapidamente e ajudará a mitigar a ansiedade que os proprietários de aplicativos podem sentir à medida que seus serviços migram para a nuvem.

O ato de levantar e transferir também pode atuar como um catalisador para restabelecer controles robustos, racionalizar o acesso e melhorar a continuidade dos negócios, o que aumentará o ROI geral da migração. Por fim, se você estiver aproveitando várias nuvens públicas, considere os benefícios de colocalizar em uma troca de nuvem, o que pode melhorar o desempenho e permitir que você padronize as políticas de segurança e acesso a partir de um único ponto de controle.

¹ Português Knapp, Kristin, “The Means to the End”, Modern Infrastructure, julho/agosto de 2015, http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf .