Vai migrar aplicativos para a nuvem? Leia isto primeiro.
Introdução
Os ambientes de computação em nuvem são hoje um elemento predominante no cenário de TI, com as organizações migrando aplicações legadas locais para a nuvem com uma frequência cada vez maior. No entanto, migrar uma aplicação para a nuvem exige mais do que simplesmente transferi-la para uma máquina virtual de um provedor de nuvem. Diferentes organizações têm motivações distintas para a migração para a nuvem, mas há fatores essenciais que todas devem considerar, além de práticas recomendadas que certamente ajudam a garantir o sucesso desse processo. Para aproveitar ao máximo os benefícios da migração para a nuvem, planeje-se com antecedência — tanto em relação à arquitetura da aplicação quanto à transição do ambiente local para a nuvem.
Visão geral
Nuvem vs. infraestrutura local: principais diferenças
Um ambiente de nuvem funciona de maneira diferente de um ambiente local. Algumas das diferenças entre os dois ambientes são óbvias, como o fato de os recursos computacionais pertencerem a outra empresa e serem gerenciados por ela, em vez de pertencerem à própria organização e serem gerenciados internamente. No entanto, várias das diferenças mais importantes não estão relacionadas à tecnologia. Em geral, qualquer tecnologia disponibilizada por um provedor de nuvem também está disponível localmente. O que a nuvem oferece é um modelo de consumo alternativo, e não uma tecnologia alternativa. Em outras palavras, as vantagens de migrar para um provedor de nuvem estão na forma como os recursos computacionais são consumidos, não nos recursos computacionais em si.
Os provedores de nuvem não conseguem necessariamente reproduzir todos os recursos disponíveis em ambientes locais, como políticas de conformidade para auditoria de dados desenvolvidas para hardware local. Como os componentes da nuvem estão geograficamente dispersos, a latência costuma ser maior em implantações na nuvem. Os provedores de nuvem também enfrentam outras limitações. Como seguem padrões comuns a todos os clientes, há limites concretos para a personalização dos ambientes computacionais. Por exemplo, poucos provedores de nuvem disponibilizam equipamentos computacionais raros e exóticos.
Mas, se uma empresa puder operar dentro desses limites, um provedor de nuvem poderá oferecer recursos de consumo que estão fora do alcance da maioria das empresas. Um provedor de nuvem pode operar data centers em todo o mundo, permitindo que as organizações escolham em qual deles alocar seus recursos computacionais. Um provedor de nuvem também pode absorver custos fixos, possibilitando que uma empresa pague apenas pelos recursos efetivamente utilizados. Como um provedor de nuvem conta com economias de escala que a maioria das empresas não consegue igualar, ele pode investir pesadamente em sistemas para gerenciar e automatizar implantações. Observe que nenhum desses benefícios é de natureza técnica; na verdade, as vantagens de um provedor de nuvem estão nas opções e na estrutura de custos disponíveis para o consumidor.
Para mitigar as limitações e aproveitar as vantagens de um provedor de nuvem, um departamento de TI deve mudar a forma como implanta aplicações, adaptando os fluxos de trabalho para tirar o máximo proveito dos pontos fortes de um provedor de nuvem e, ao mesmo tempo, evitando dependências de atributos nos quais um ambiente de nuvem está em desvantagem, como a latência.

Motivações para a migração para a nuvem
A redução de custos é frequentemente mencionada como um dos principais motivos para migrar para a nuvem, mas as verdadeiras razões costumam ser mais complexas. A maioria das motivações se enquadra em três categorias: previsibilidade, produtividade e agilidade.
Os provedores de nuvem pública aumentam a previsibilidade ao oferecer tecnologias em pacotes que facilitam seu consumo e, com isso, absorvem parte do risco operacional de TI. Como os provedores mantêm a infraestrutura e assumem a responsabilidade por ela, a organização não precisa se preocupar com essas questões. Da mesma forma, os provedores de nuvem geralmente disponibilizam ferramentas que permitem obter informações sobre as operações de TI, aumentando a visibilidade. Como os custos da nuvem pública geralmente variam de acordo com o consumo, a organização pode vincular mais diretamente os benefícios de uma aplicação (como a receita) aos seus custos operacionais. À medida que o uso da aplicação aumenta, os custos também aumentam, assim como os benefícios. Ao transferir as despesas de capital para despesas operacionais, há menos necessidade de prever uma margem para o crescimento futuro nas decisões de compra. Gerenciar essas incertezas no âmbito do provedor de nuvem gera benefícios mensuráveis.
Outro motivo para adotar a nuvem pública é o aumento da produtividade. As ferramentas de colaboração e automação oferecidas pelos provedores estão entre as mais avançadas disponíveis no mercado. Além disso, não precisar gerenciar a infraestrutura permite que a equipe de TI se concentre em iniciativas estratégicas para os negócios, enquanto operações simplificadas, que podem ser gerenciadas de qualquer lugar, aumentam a produtividade da equipe de TI.
O último motivo para adotar a nuvem pública talvez seja o mais convincente: a agilidade. Como o provedor de nuvem cria a ilusão de recursos infinitos disponíveis a qualquer momento, a velocidade e o direcionamento das iniciativas de negócios deixam de estar vinculados às limitações de provisionamento de TI. Os recursos podem ser implantados em segundos ou minutos. Um projeto pode utilizar um ambiente computacional complexo por um curto período sem a preocupação de desativar o hardware quando for encerrado. Os aplicativos podem ser implantados, dimensionados e removidos rapidamente, sem preocupação com os ativos de hardware.
Barreiras à migração para a nuvem
Embora a migração para a nuvem ofereça muitos benefícios, esse processo também apresenta diversos desafios. As barreiras e os riscos variam de acordo com a etapa do processo em que ocorrem: antes, durante ou após a migração. Abordar essas barreiras e esses riscos antecipadamente aumenta a probabilidade de uma migração bem-sucedida.
O planejamento antes da migração talvez seja a parte mais crítica do processo. As iniciativas de migração podem fracassar caso a aplicação não seja rearquitetada para aproveitar os recursos da nuvem. Esse também é um bom momento para avaliar e começar a gerenciar a complexidade da aplicação. O treinamento da equipe de TI também deve ocorrer no início da iniciativa. As implantações em nuvem tendem a resultar em uma execução isolada e na proliferação de ferramentas, e o planejamento nas fases iniciais pode ajudar a tornar o processo de migração mais tranquilo.
A migração de aplicações para a nuvem costuma levar mais tempo e ser mais complexa do que o planejado inicialmente. Para ajudar a minimizar os problemas, comece com uma aplicação pequena e relativamente independente, para que eventuais problemas tenham um impacto mínimo. As lições aprendidas com a primeira migração de uma aplicação pequena podem ser aplicadas a migrações futuras.
Os problemas de longo prazo relacionados às migrações tornam-se evidentes após a conclusão da migração. Podem surgir preocupações com segurança e conformidade, muitas vezes porque é mais difícil definir o perímetro de segurança em um ambiente de nuvem. O suporte a sistemas legados pode ser mais difícil quando os sistemas antigos e novos não apenas estão em ambientes diferentes, mas também foram desenvolvidos com culturas distintas. Algumas organizações têm demonstrado preocupação com a dependência de um único provedor de nuvem, especialmente com a ascensão dos contêineres. Por fim, questões orçamentárias podem ser um problema, pois pode ser difícil projetar trimestralmente os custos variáveis da nuvem.
Como escolher quais aplicativos migrar
Uma técnica para avaliar aplicações é a matriz de maturidade versus localização. Analise suas aplicações para determinar o nível de maturidade necessário. Aplicações que proporcionam diferenciação competitiva ou atendem a nichos específicos podem ser mais adequadas para ambientes locais. No outro extremo do espectro, aplicações de baixo custo ou com liderança em custos (especialmente no que diz respeito ao custo das mudanças) costumam se adaptar bem a um ambiente de nuvem. Outros fatores a considerar incluem a escalabilidade. Suponha que uma nova aplicação tenha sido implantada e possa, no futuro, atingir uma carga 100 vezes maior que a atual. Para acompanhar esse crescimento em uma implantação local, seria necessário superdimensionar significativamente a infraestrutura, gerando custos adicionais de capital com recursos ociosos. No entanto, se essa mesma aplicação fosse implantada em um ambiente de nuvem, os custos aumentariam de acordo com o crescimento, sem a necessidade de superdimensionamento.

Questões de rede também podem influenciar a decisão sobre quais aplicações migrar para um ambiente de nuvem. Se uma aplicação tiver uma grande proporção de usuários distribuídos, como uma ampla rede de revendedores, ou um número considerável de usuários remotos de e-mail, uma implantação local direcionará todo esse tráfego para o data center. Como o tráfego já percorre a Internet, as aplicações não são sensíveis à latência. Quando aplicações como essas são transferidas para um ambiente de nuvem, a latência da rede não muda, mas há liberação de largura de banda nos data centers locais que, de outra forma, seria consumida pelos usuários distribuídos.
Ao mesmo tempo, há motivos para manter alguns aplicativos no ambiente local. Talvez não valha a pena assumir os riscos e custos de migrar aplicativos com vida útil mais curta. Alguns aplicativos dependem de baixa latência de rede e altas velocidades de armazenamento e podem apresentar um desempenho muito pior em um ambiente de nuvem. Questões de conformidade e segurança costumam ser citadas como motivos para manter aplicativos no ambiente local. Alguns procedimentos de auditoria pressupõem acesso físico aos sistemas e aos dados para verificá-los, enquanto outros exigem que o aplicativo e o sistema operacional sejam executados diretamente no hardware (ou seja, não podem ser executados em uma máquina virtual). Com o tempo, os procedimentos de conformidade se adaptarão ao ambiente de nuvem, mas, em muitos casos, isso ainda não aconteceu. Em vez de correr o risco de não passar em auditorias de conformidade por manter aplicativos na nuvem, talvez seja mais sensato manter esses aplicativos confidenciais no ambiente local por enquanto. Alguns aplicativos precisam oferecer suporte a sistemas e processos legados e, portanto, não podem ser rearquitetados de forma viável para operar na nuvem. Esses aplicativos também podem ser candidatos a permanecer no ambiente local. Por esses motivos, alguns aplicativos devem ter uma prioridade de migração menor do que aqueles mais adequados a um ambiente de nuvem.
Aplicações que devem permanecer no ambiente local
- Aplicativos com vida útil curta
- Aplicativos que exigem baixa latência
- Aplicativos sujeitos a requisitos de conformidade
- Aplicativos compatíveis com sistemas legados
Considerações sobre a transição
Muitas organizações precisam superar desafios durante o processo de migração. Uma questão importante que precisará ser respondida é: como realizar a transição propriamente dita? Uma abordagem é usar o DNS para direcionar à aplicação local até que a aplicação na nuvem tenha sido completamente testada e, em seguida, alterar os registros DNS para direcionar à aplicação na nuvem. O DNS contém um valor de tempo de vida (TTL) que permite aos clientes armazenar a resposta DNS em cache por determinado período. Antes da transição, pode ser conveniente definir um TTL baixo, talvez de apenas alguns segundos, para que, após a transição, os clientes sejam rapidamente direcionados às novas aplicações. No entanto, essa abordagem apresenta alguns riscos. Reduzir o TTL pode aumentar significativamente o tráfego DNS e a carga sobre os servidores. Uma organização pode ignorar o TTL e manter o cache por períodos maiores do que os especificados, fazendo com que alguns usuários continuem sendo direcionados à aplicação local muito tempo após a transição. Considere testar a robustez da sua infraestrutura de DNS antes de usar essa abordagem.
O processo de transição também pode revelar problemas no novo aplicativo que não foram identificados durante os testes. Uma forma de se proteger contra problemas no aplicativo é ter um plano de contingência que permita reverter o processamento para o aplicativo local em caso de falhas. Infelizmente, uma transição bidirecional complica a sincronização de dados e, portanto, exige muito mais planejamento e testes prévios. Uma abordagem mais sofisticada utiliza uma transição parcial, chamada teste canário, na qual uma parte dos usuários é transferida para o aplicativo em nuvem enquanto ele é monitorado. À medida que aumenta a confiança no aplicativo, mais usuários — e, por fim, todos — podem ser transferidos. Por outro lado, caso surja algum problema, os usuários transferidos podem voltar a usar o aplicativo local. O teste canário pode ser realizado por um Application Delivery Controller (ADC) programável por meio do F5® iRules®, minimizando os riscos e ampliando as opções disponíveis para a equipe de operações durante o período de transição.

Recomendações
Desenvolva aplicativos de forma diferente para a nuvem
Um dos maiores erros que as organizações cometem ao migrar aplicações é não reformulá-las para a nuvem. Reservar tempo para alterar a estrutura da aplicação de modo que ela aproveite as particularidades de um ambiente de nuvem pode trazer benefícios significativos.
Por exemplo, o escalonamento em um ambiente de nuvem é trivial em comparação com o escalonamento em uma infraestrutura local. Em vez de projetar a aplicação e testá-la para a pior carga possível, projete-a para ser enxuta, mas escalável. Não há necessidade de manter a sobrecarga de uma infraestrutura de grande porte quando o uso da aplicação varia muito. Em vez disso, comece com uma estrutura pequena e esteja preparado para escalar. Da mesma forma, determinadas falhas, como quedas de energia, são menos prováveis em um ambiente de nuvem, portanto há menos necessidade de projetar a aplicação para lidar com elas.
Por outro lado, os ambientes de nuvem introduzem novas limitações que normalmente não são encontradas em ambientes locais. Os arquitetos de nuvem observam que um projeto deve prever a falha de qualquer instância de VM a qualquer momento como parte do processamento normal. O armazenamento também é diferente em um ambiente de nuvem. Projetos locais costumam usar armazenamento em blocos local. Essa mesma opção está disponível em ambientes de nuvem, mas não pode ser compartilhada. A combinação de estado local não compartilhado e falha de instância pode ser uma receita para o desastre. Existem outros paradigmas de armazenamento, como armazenamento baseado em objetos ou serviços de armazenamento de chave-valor. É possível contornar as limitações de um ambiente de nuvem por meio da reformulação da arquitetura da aplicação.
Considere o que manter no ambiente local
Faz sentido manter alguns aplicativos ou sistemas de controle no ambiente local. Muitas organizações manterão o Active Directory localmente e usarão a federação para estender a identidade a um ambiente de nuvem. Da mesma forma, um ADC oferece diversos serviços de segurança para dar suporte à entrega de aplicativos, como firewalls, firewalls de aplicativos Web, proteção contra DDoS e interceptação de SSL/TLS, além do encadeamento de serviços. Um ADC também oferece gerenciamento avançado de tráfego e um proxy programável, bem como gerenciamento de identidades e acesso.
Tradicionalmente, as organizações consolidam esses serviços de aplicação fora da aplicação, pois eles não fazem parte da lógica de negócios, mas são questões operacionais. Para viabilizar mudanças operacionais independentemente dos cronogramas de lançamento das aplicações, muitas empresas concentram conhecimentos especializados que podem ser aplicados a todas as aplicações, usando um ADC como ponto estratégico de controle. No entanto, os ambientes de nuvem mudam esse modelo.
Uma das primeiras abordagens para a entrega de aplicações em ambientes de nuvem consistia em replicar os serviços de ADC usando ferramentas nativas de cada ambiente de nuvem. Logo ficou evidente que os provedores de nuvem não ofereciam o mesmo nível de recursos nativos, o que deixou as organizações diante de uma escolha: manter padrões heterogêneos de entrega de aplicações entre ambientes de nuvem e locais ou reformular todas as aplicações com base no menor denominador comum.
À medida que as empresas se expandiam para vários ambientes de nuvem, ambas as opções se tornavam menos atraentes. Suponha que uma organização utilize três provedores de nuvem e também mantenha um data center local. A organização precisava manter quatro conjuntos de especialistas em SSL/TLS, quatro conjuntos de especialistas em DDoS e assim por diante, ou padronizar um conjunto cada vez mais fragmentado (e limitado) de serviços básicos. A implantação de apenas uma nova aplicação em um ambiente de nuvem adicional acarretava um custo marginal significativo, seja pela necessidade de outra equipe de especialistas no domínio, seja pela criação de um novo conjunto de padrões a ser aplicado a todas as aplicações existentes.
Mas há uma terceira opção para fornecer serviços consistentes em todos os ambientes. O F5 Application Connector permite que uma única equipe de especialistas no domínio gerencie todas as aplicações, independentemente de onde elas estejam hospedadas. Ao usar dispositivos de hardware ou software BIG-IP® existentes, uma organização pode implementar serviços avançados e completos na frente de qualquer aplicação, onde quer que ela esteja localizada, proporcionando a todas as aplicações um ponto estratégico de controle, gerenciado por uma única equipe de especialistas no domínio. Além disso, o Application Connector reforça a segurança ao eliminar todos os endereços IP públicos visíveis, reduzindo assim as superfícies de ataque. Ao manter as chaves de criptografia armazenadas centralmente, e não nas instâncias de nuvem, as organizações podem ter a certeza de que suas informações criptográficas críticas permanecerão privadas. Por fim, o Application Connector aumenta a eficiência da implantação na nuvem ao permitir que novos nós de carga de trabalho sejam descobertos automaticamente pela instância de proxy.

Considere cuidadosamente o armazenamento
Uma das maiores diferenças entre aplicações locais e aplicações em nuvem é o armazenamento do estado da aplicação. Na grande maioria dos casos, as arquiteturas locais usam armazenamento em blocos local, como um disco rígido ou uma unidade de estado sólido. Uma aplicação em nuvem também pode usar armazenamento em blocos, mas esse armazenamento é local à instância, e as arquiteturas devem prever possíveis falhas nas instâncias. Se as organizações não reformularem nenhum outro aspecto da arquitetura ao migrar uma aplicação para a nuvem, devem ao menos mudar a forma como o estado é gerenciado.
Um tipo comum de armazenamento em nuvem é o armazenamento de objetos, no qual cada objeto é essencialmente um arquivo, mas é acessado por meio de um nome. Em geral, o armazenamento tem, no máximo, um nível de hierarquia (ou seja, pasta ou diretório), portanto, mapear um sistema de arquivos tradicional para objetos pode ser problemático. Como os objetos não podem ser editados — apenas criados, lidos e excluídos —, o armazenamento de objetos é uma boa opção para conteúdo estático, como imagens, mas não para armazenar o estado da aplicação. Muitos aplicativos pressupõem que um arquivo possa ser modificado e, por isso, não funcionam com objetos.
Outras opções de armazenamento incluem repositórios de chave-valor e bancos de dados transacionais tradicionais. Eles não são sistemas de armazenamento como um sistema de arquivos, mas armazenam dados e são oferecidos como um serviço adicional. Com um projeto eficaz, o estado pode ser armazenado em um serviço de chave-valor ou de banco de dados.

Conclusão: prepare-se antes de migrar
Os ambientes de computação em nuvem oferecem benefícios, mas somente se os principais aplicativos tiverem sua arquitetura reformulada para aproveitar os recursos da nuvem e, ao mesmo tempo, reduzir o impacto de suas limitações. Os ambientes de nuvem apresentam diferentes cenários de falha e, muitas vezes, maior latência de rede, mas permitem escalabilidade rápida e a escolha de data centers em todo o mundo. Entre os aspectos a serem considerados na migração para a nuvem está a definição de quais aplicativos migrar e quais manter no ambiente local.
O próprio processo de transição também deve ser cuidadosamente analisado e planejado, incluindo um plano de reversão caso a aplicação na nuvem não se comporte conforme o esperado. Como parte do processo de planejamento, algumas organizações mantêm um ADC localmente como um ponto estratégico de controle para todas as aplicações, independentemente de onde estejam hospedadas. Por fim, planeje cuidadosamente como a aplicação na nuvem armazenará dados e estados. Seja qual for a estratégia escolhida para migrar suas aplicações — e sua empresa — para a nuvem, considere contar com um parceiro experiente em nuvem.
PUBLICADO EM 16 DE AGOSTO DE 2017
