Migrando aplicativos para a nuvem? Leia isto primeiro.

INTRODUÇÃO

Os ambientes de computação em nuvem são agora uma característica dominante do cenário de TI, com organizações movendo aplicativos locais legados para a nuvem com regularidade cada vez maior. Mas migrar um aplicativo para a nuvem exige mais do que simplesmente mover o aplicativo para uma máquina virtual em um provedor de nuvem. Diferentes organizações têm motivações diferentes para a migração para a nuvem, mas há fatores-chave que cada organização deve considerar e certamente há práticas recomendadas para ajudar a garantir um esforço de migração para a nuvem bem-sucedido. Para obter o máximo de benefícios da migração para a nuvem, planeje com antecedência, tanto na arquitetura do aplicativo quanto na transição do ambiente local para a nuvem.

visão geral
Nuvem vs. local: principais diferenças

Um ambiente de nuvem se comporta de maneira diferente de um ambiente local. Algumas das distinções entre os dois ambientes são óbvias, como o fato de que os recursos de computação são de propriedade e gerenciados por outra empresa, em vez de serem de propriedade e gerenciados internamente. Várias das diferenças mais importantes, no entanto, não são uma função da tecnologia. Em geral, qualquer tecnologia disponível em um provedor de nuvem também está disponível no local. O que a nuvem oferece é um modelo de consumo alternativo, não uma tecnologia alternativa. Em outras palavras, as vantagens de migrar para um provedor de nuvem estão na forma como os recursos de computação são consumidos, não nos recursos de computação em si.

Os provedores de nuvem não podem necessariamente duplicar todos os recursos locais, como políticas de conformidade de auditoria de dados projetadas para hardware local. Como os componentes da nuvem são dispersos geograficamente, a latência geralmente é pior em implantações na nuvem. Os provedores de nuvem também enfrentam outras limitações. Como os provedores seguem padrões entre clientes, existem limites reais para personalização de ambientes de computação. Por exemplo, poucos provedores de nuvem fornecerão equipamentos de computação raros e exóticos.

Mas se uma empresa puder operar dentro desses limites, um provedor de nuvem poderá fornecer recursos de consumo além do alcance da maioria das empresas. Um provedor de nuvem pode operar data centers em todo o mundo, oferecendo às organizações a opção de escolher em qual data center localizar recursos de computação. Um provedor de nuvem também pode absorver custos fixos, permitindo que uma empresa pague apenas pelos recursos realmente utilizados. Como um provedor de nuvem tem economias de escala inigualáveis à maioria das empresas, ele pode investir pesadamente em sistemas para gerenciar e automatizar implantações. Observe que nenhum desses benefícios é de natureza técnica; em vez disso, as vantagens de um provedor de nuvem estão nas opções e na estrutura de custos disponíveis para o consumidor.

Para atenuar os limites e aproveitar as vantagens de um provedor de nuvem, um departamento de TI deve mudar a maneira como implanta aplicativos, alterando os fluxos de trabalho para aproveitar ao máximo os pontos fortes relativos de um provedor de nuvem, evitando dependências de atributos em que um ambiente de nuvem está em desvantagem, como latência.

Diagrama das principais diferenças entre ambientes locais e em nuvem
Figura 1: Principais diferenças entre ambientes locais e de nuvem
Motivações para migração para a nuvem

A economia de custos é frequentemente mencionada como o principal motivador para migrar para a nuvem, mas os verdadeiros motivos tendem a ser mais sutis. A maioria das motivações se enquadra em três categorias: certeza, produtividade e agilidade.

Os provedores de nuvem pública aumentam a certeza ao empacotar a tecnologia para torná-la mais consumível e, ao fazer isso, absorvem parte do risco operacional de TI. Como os provedores mantêm e assumem a responsabilidade pela infraestrutura, uma organização pode ignorar essas preocupações. Da mesma forma, os provedores de nuvem geralmente disponibilizam ferramentas para obter insights sobre as operações de TI, aumentando a visibilidade. Como os custos da nuvem pública geralmente são uma função do consumo, uma organização pode vincular mais estreitamente os benefícios de um aplicativo (como receita) aos custos operacionais desse aplicativo. À medida que o aplicativo é mais utilizado, os custos aumentam, mas os benefícios também. Ao mover as despesas de capital para operacionais, há menos necessidade de abrir espaço para crescimento futuro nas decisões de compra. Gerenciar essas incertezas no nível do provedor de nuvem oferece benefícios mensuráveis.

Outro motivo para adotar a nuvem pública é o aumento da produtividade. As ferramentas de colaboração e automação dos provedores estão entre as mais avançadas disponíveis no mercado. Além disso, não gerenciar a infraestrutura libera a equipe de TI para se concentrar em esforços estratégicos de 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 o mais convincente: agilidade. Como o provedor de nuvem cria a ilusão de recursos infinitos disponíveis a qualquer momento, a velocidade e a direção dos esforços comerciais não estão mais vinculadas às restrições de provisionamento de TI. Os recursos podem ser implantados em segundos ou minutos. Um projeto pode consumir um ambiente de computação complexo por um curto período de tempo sem se preocupar em desativar o hardware quando o projeto terminar. Os aplicativos podem ser implantados, dimensionados e removidos rapidamente sem preocupação com ativos de hardware.

Barreiras à migração para a nuvem

Embora haja muitos benefícios na migração para a nuvem, há vários desafios associados a esse esforço. As barreiras e os riscos variam dependendo de onde ocorrem no processo de migração: antes da migração, durante a migração e depois da migração. Abordar essas barreiras e riscos antecipadamente aumenta a probabilidade de um esforço de migração bem-sucedido.

O planejamento antes da migração é talvez a parte mais crítica do processo de migração. Os esforços de migração podem falhar devido a uma falha na reformulação da arquitetura do aplicativo para aproveitar os recursos da nuvem. Este também é um bom momento para fazer um balanço e começar a gerenciar a complexidade do aplicativo. O treinamento de TI também deve ocorrer no início do esforço. As implantações em nuvem tendem à execução isolada e à proliferação de ferramentas, e o planejamento nas fases iniciais pode ajudar a facilitar o processo de migração.

A migração de aplicativos para a nuvem tende a demorar mais e ser mais complexa do que o planejado inicialmente. Para ajudar a minimizar problemas, comece com um aplicativo pequeno e relativamente independente para que os problemas encontrados tenham impacto mínimo. As lições aprendidas na primeira migração de um pequeno aplicativo podem ser aplicadas em migrações futuras.

Problemas de longo prazo com migrações tornam-se aparentes após a conclusão da migração. Podem surgir preocupações com segurança e conformidade, geralmente porque o perímetro de segurança é mais difícil de definir em um ambiente de nuvem. O suporte para sistemas legados pode ser mais difícil quando sistemas antigos e novos não estão apenas em ambientes diferentes, mas são desenvolvidos com culturas diferentes. Algumas organizações têm se preocupado com o bloqueio da nuvem, especialmente com o surgimento dos contêineres. Por fim, as preocupações com o orçamento podem ser um problema, já que os custos variáveis da nuvem podem ser difíceis de projetar a cada trimestre.

Como escolher quais aplicativos migrar

Uma técnica para avaliar aplicações é a matriz de maturidade versus localização. Analise suas inscrições para determinar quanta maturidade você precisa. Aplicações que proporcionam diferenciação competitiva ou são de nicho podem ser melhor atendidas no local. No outro extremo do espectro, aplicativos de baixo custo ou de liderança em custos (particularmente no custo de mudança) geralmente se adaptam bem a um ambiente de nuvem. Outros fatores a serem considerados incluem escalabilidade. Suponha que um novo aplicativo tenha sido implantado e possa eventualmente ser dimensionado para 100 vezes a carga atual. Para se manter à frente do crescimento da implantação local, a infraestrutura precisaria ser significativamente superprovisionada, introduzindo custos de capital extras para recursos ociosos. No entanto, se esse mesmo aplicativo fosse implantado em um ambiente de nuvem, os custos aumentariam com o crescimento e não haveria necessidade de provisionamento excessivo.

Escolhendo quais aplicativos migrar para o diagrama de nuvem
Figura 2: Escolhendo quais aplicativos migrar para a nuvem

Problemas de rede também podem desempenhar um papel na decisão de quais aplicativos migrar para um ambiente de nuvem. Se um aplicativo tiver uma grande proporção de usuários distribuídos, como uma rede de revendedores expansiva, ou um número considerável de usuários de e-mail remotos, uma implantação local canalizará todo esse tráfego para o data center. Como o tráfego já está passando pela Internet, os aplicativos não são sensíveis à latência. Quando aplicativos como esses são colocados em um ambiente de nuvem, a latência da rede não muda, mas libera largura de banda em data centers locais que, de outra forma, seriam consumidos pelos usuários distribuídos.

Ao mesmo tempo, há motivos para manter alguns aplicativos no local. Aplicativos com expectativa de vida mais curta podem não valer os riscos e custos de um esforço de migração. Alguns aplicativos dependem de baixa latência de rede e velocidades de armazenamento e podem ter um desempenho muito pior em um ambiente de nuvem. Preocupações com conformidade e segurança geralmente surgem como motivos para manter aplicativos no local. Alguns procedimentos de auditoria pressupõem acesso físico aos sistemas e dados para verificar os dados, enquanto outros exigem que o aplicativo e o sistema operacional sejam executados em bare metal (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 assumir o risco de falhar em auditorias de conformidade com aplicativos na nuvem, pode fazer mais sentido manter esses aplicativos confidenciais no local por enquanto. Alguns aplicativos precisam dar suporte a sistemas e processos legados e, portanto, não podem ser reprojetados para operar em uma nuvem. Esses aplicativos também podem ser candidatos a permanecer no local. Por esses motivos, alguns aplicativos devem ter uma prioridade de migração menor do que aplicativos que se adaptam melhor a um ambiente de nuvem.

É melhor deixar os aplicativos no local

  • Aplicativos com curta expectativa de vida
  • Aplicativos que exigem baixa latência
  • Aplicativos para os quais há preocupações de conformidade
  • Aplicativos que suportam 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 precisa ser respondida é como realizar a transição real? Uma abordagem é usar o DNS para resolver o aplicativo local até que o aplicativo na nuvem tenha sido completamente testado e, então, alterar os registros DNS para resolver o aplicativo na nuvem. O DNS contém um valor de tempo de vida (TTL) que permite que os clientes armazenem em cache a resposta do DNS por um período de tempo. Antes da transição, pode fazer sentido definir um TTL baixo, talvez apenas alguns segundos, para que, após a transição, os clientes resolvam rapidamente para os novos aplicativos. No entanto, essa abordagem tem alguns riscos. Reduzir o TTL pode aumentar significativamente o tráfego DNS, bem como a carga nos servidores. Uma organização pode ignorar o TTL e o cache por períodos mais longos do que o especificado, deixando alguns usuários resolvendo para o aplicativo local muito tempo depois que a transferência ocorreu. Considere testar a robustez da sua infraestrutura de DNS antes de usar essa abordagem.

O processo de transição também pode expor problemas com o novo aplicativo que não foram encontrados nos testes. Uma maneira de se proteger contra um aplicativo problemático é um plano de fallback que permite que o processamento reverta para o aplicativo local em caso de problemas. Infelizmente, uma transição bidirecional complica a sincronização de dados e, portanto, exige muito mais planejamento e testes iniciais. Uma abordagem mais sofisticada usa uma transição parcial chamada teste canário, que transfere uma parte dos usuários para o aplicativo em nuvem enquanto ele é monitorado. À medida que a confiança no aplicativo aumenta, mais usuários (e eventualmente todos) podem ser transferidos. Por outro lado, caso surja um 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 assim os riscos e aumentando o número de opções abertas à equipe de operações durante o período de transição.

Preparando o diagrama do processo de transição
Figura 3: Preparando-se para o processo de transição
Recomendações
Crie aplicativos de forma diferente para a nuvem

Um dos maiores erros que as organizações cometem ao migrar aplicativos é não reestruturar esses aplicativos para a nuvem. Alocar tempo para alterar a estrutura do aplicativo para que ele aproveite as diferenças em um ambiente de nuvem pode gerar benefícios significativos.

Por exemplo, o dimensionamento em um ambiente de nuvem é trivial comparado ao dimensionamento local. Em vez de projetar o aplicativo e testá-lo para a pior carga possível, projete-o para que seja enxuto, mas escalável. Não há necessidade de manter sobrecarga para uma grande área de cobertura quando o uso do aplicativo abrange um amplo espectro. Em vez disso, construa pequeno e esteja pronto para escalar. Da mesma forma, certas falhas, como falta de energia, são menos prováveis em um ambiente de nuvem, então há menos necessidade de arquitetura para elas.

Por outro lado, os ambientes de nuvem introduzem novas limitações que não são comumente vivenciadas no local. Arquitetos de nuvem observam que um design deve planejar falhas de qualquer instância de VM a qualquer momento como parte do processamento regular. O armazenamento também é diferente em um ambiente de nuvem. Projetos locais usam regularmente armazenamento em bloco local. A 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 proteger-se contra as limitações de um ambiente de nuvem por meio da rearquitetura do aplicativo.

Considere o que manter nas instalações

Faz sentido manter alguns aplicativos ou sistemas de controle no local. Muitas organizações manterão o Active Directory local enquanto empregam federação para estender a identidade em um ambiente de nuvem. Da mesma forma, um ADC fornece muitos serviços de segurança para dar suporte à entrega de aplicativos, como firewalls, firewalls de aplicativos web, proteção DDoS e interceptação SSL/TLS, juntamente com encadeamento de serviços. Um ADC também fornece gerenciamento avançado de tráfego e um proxy programável, bem como gerenciamento de identidade e acesso.

As organizações normalmente consolidam esses serviços de aplicativos externamente ao aplicativo porque os serviços não fazem parte da lógica de negócios, mas são preocupações operacionais. Para permitir mudanças operacionais independentes dos cronogramas de lançamento de aplicativos, muitas empresas concentram conhecimento de domínio que pode ser aplicado a todos os aplicativos usando um ADC como um ponto estratégico de controle. No entanto, os ambientes de nuvem mudam esse modelo.

Uma abordagem inicial para entrega de aplicativos em ambientes de nuvem era replicar serviços de ADC usando ferramentas nativas em cada ambiente de nuvem. Logo ficou claro que os provedores de nuvem não ofereciam o mesmo nível de recursos nativos, o que deixou as organizações com uma escolha: manter padrões heterogêneos de entrega de aplicativos entre os ambientes de nuvem e locais ou redesenhar todos os aplicativos para o menor denominador comum.

À medida que as empresas se expandiram para vários ambientes de nuvem, ambas as opções se tornaram menos aceitáveis. 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 conhecimentos em SSL/TLS, quatro conjuntos de conhecimentos em DDoS e assim por diante, ou precisava padronizar um conjunto cada vez mais desconexo (e limitado) de serviços básicos. A implantação de apenas um novo aplicativo em um ambiente de nuvem adicional acarretava um custo marginal significativo de outro conjunto de especialistas de domínio ou de um novo conjunto de padrões a serem aplicados a todos os aplicativos existentes.

Mas há uma terceira opção para fornecer serviços consistentes em todos os ambientes. O F5 Application Connector permite que um conjunto de especialistas em domínio gerencie todos os aplicativos, independentemente de onde eles estejam. Ao usar dispositivos de hardware ou software BIG-IP® existentes, uma organização pode injetar serviços de aplicativos avançados completos na frente de qualquer aplicativo, onde quer que ele esteja localizado, dando a todos os aplicativos um ponto estratégico de controle, gerenciado por um único conjunto de especialistas no domínio. Além disso, o Application Connector aumenta a segurança eliminando 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 da nuvem, as organizações podem ter certeza de que suas informações criptográficas críticas permanecerão privadas. Por fim, o Application Connector aumenta a eficiência da sua implantação na nuvem permitindo que novos nós de carga de trabalho sejam descobertos automaticamente pela instância do proxy.

Como o Application Connector facilita a transição para o diagrama de nuvem
Figura 4: Como o Application Connector facilita a transição para a nuvem
Considere cuidadosamente o armazenamento

Uma das maiores diferenças entre aplicativos locais e aplicativos em nuvem é o armazenamento do estado do aplicativo. A grande maioria dos projetos locais usa armazenamento em bloco local, como um disco rígido ou uma unidade de estado sólido. Um aplicativo em nuvem também pode usar armazenamento em bloco, mas o armazenamento é local na instância e os projetos devem esperar que as instâncias falhem. Se as organizações não reformularem mais nada no design do aplicativo ao mover um aplicativo para a nuvem, elas devem mudar a forma como o estado é manipulado.

Um tipo comum de armazenamento em nuvem é o armazenamento de objetos, onde cada objeto é essencialmente um arquivo, mas endereçado usando um nome. Geralmente, o armazenamento tem no máximo um nível de hierarquia (por exemplo, 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 escolha para conteúdo estático, como imagens, mas não é uma boa escolha para estado. Muitos aplicativos assumem que um arquivo pode ser modificado, portanto, esses aplicativos não funcionarão com objetos.

Outras opções de armazenamento incluem armazenamentos de chave-valor e bancos de dados transacionais tradicionais. Eles não são armazenamentos como um sistema de arquivos, mas armazenam dados e são fornecidos como um serviço adicional. Com um design eficaz, o estado pode ser armazenado em um serviço de chave-valor ou de banco de dados.

Tipo de armazenamento

Prós

Contras

Bloquear

Idêntico ao armazenamento tradicional

Não pode ser compartilhado

Objeto

Rápido
Compartilhável

Não pode ser editado
Apenas um nível de hierarquia

Chave/Valor

Rápido
Compartilhável

Suporte limitado a transações

Banco de Dados Relacional

Transacional
Bem compreendido

Desempenho limitado

Figura 5: Características dos tipos de armazenamento
Conclusão: prepare-se antes de migrar

Os ambientes de computação em nuvem oferecem benefícios, mas somente se os principais aplicativos forem reprojetados para aproveitar os recursos da nuvem e, ao mesmo tempo, mitigar o impacto das limitações da nuvem. Os ambientes de nuvem têm diferentes cenários de falha e geralmente apresentam maior latência de rede, mas permitem dimensionamento rápido e escolha de data centers em todo o mundo. As considerações para a migração para a nuvem incluem determinar quais aplicativos migrar e quais manter no local.

O processo de transição em si também deve ser cuidadosamente pensado e planejado, juntamente com um plano de retorno caso o aplicativo em nuvem não esteja se comportando como esperado. Como parte do processo de planejamento, algumas organizações mantêm um ADC local como um ponto estratégico de controle para todos os aplicativos, independentemente de onde estejam hospedados. Por fim, planeje cuidadosamente como o aplicativo em nuvem armazenará dados e estado. Independentemente de como você escolher mover seus aplicativos — e seus negócios — para a nuvem, considere trazer um parceiro de nuvem experiente com você.

Publicado em 16 de agosto de 2017
  • Compartilhe no Facebook
  • Compartilhar para X
  • Compartilhe no Linkedin
  • Compartilhar por e-mail
  • Compartilhe via AddThis

Conecte-se com F5

F5 LABS

O que há de mais moderno em inteligência de ameaças a aplicativos.

DevCentral

A comunidade F5 para fóruns de discussão e artigos de especialistas.

Sala de redação da F5

Notícias, blogs F5 e muito mais.