Para o sucesso da migração e mudança para a nuvem, concentre-se na arquitetura

Surgiram dois modelos distintos de “migração para a nuvem”. A primeira, mais óbvia, é a abordagem nativa. Nativo significa novo, totalmente novo ou reescrito. A abordagem nativa incentiva um foco restrito no aplicativo, partindo do princípio de que, quando adaptado à nuvem, o desempenho e a segurança se tornam uma questão de provisionar os serviços certos na nuvem. O que não é totalmente verdade, mas é próximo o suficiente para que possamos continuar com isso por enquanto.

A segunda abordagem é “lift and shift”, que se concentra exatamente no que parece: levantar um aplicativo existente de sua base de data center e transferi-lo para a nuvem, onde é colocado em uma base na nuvem. Exceto que o foco não pode ser apenas no aplicativo neste modelo, porque o aplicativo tem dependências que também devem ser abordadas. Isso inclui outros componentes arquitetônicos que abrangem serviços de aplicativos e infraestrutura. 

Isso foi destacado recentemente em um relatório da Cloud Velox , com foco em aproveitar a nuvem como data center secundário. Curiosamente, ele observou esta descoberta:

Agora, o Cloud Velox estava se concentrando na recuperação de desastres, mas parece que o problema geral é mais amplamente aplicável. Transferir e elevar aplicativos para a nuvem é muito mais viável se você também puder transferir controles de rede e segurança (serviços) junto com eles.

Basicamente, se você mover um aplicativo que foi otimizado ao longo dos anos usando serviços de aplicativo hospedados na rede sem esses serviços de aplicativo, você perderá essas otimizações. Ah, existe essa crença equivocada de que simplesmente estar lá fora, na nuvem, proporciona um aumento de desempenho porque está fisicamente mais perto da espinha dorsal da Internet e dos usuários que interagem com ela, e isso é verdade, mas não totalmente. Isso ocorre porque grande parte do desempenho de um aplicativo não é determinado pela latência da rede. A verdade é que muitas das ineficiências em um aplicativo que levam a um desempenho ruim estão relacionadas ao tamanho e à composição do conteúdo, ao gerenciamento de conexão ruim e à incapacidade de ajustar adequadamente a pilha de rede para corresponder às necessidades específicas do aplicativo.

As preocupações com a segurança também não desaparecem repentinamente quando você transfere um aplicativo para a nuvem. Se o aplicativo era vulnerável a XSS ou SQLi no data center, você pode apostar que ele ainda estará vulnerável quando você o transferir para a nuvem*.  Se essas preocupações fossem abordadas no data center com um firewall de aplicativo da web ou artefatos de segurança implantados em um proxy programável, então o firewall de aplicativo e o proxy deveriam ser removidos e transferidos junto com o aplicativo.

A capacidade de “levantar e deslocar” uma arquitetura, em vez de apenas o aplicativo, é uma das razões por trás da crescente popularidade de uma opção de nuvem co-localizada. Também há argumentos para economia de custos em relação ao local e melhor controle do que na nuvem, mas certamente uma das características mais atraentes de uma opção de nuvem colocalizada é a capacidade de elevar e deslocar uma arquitetura inteira e aproveitar a "nuvem ao lado". Às vezes, as organizações desejam mover a fonte de dados para mais perto dos aplicativos implantados na nuvem para evitar a latência prejudicial ao desempenho necessária para retornar ao data center corporativo. Às vezes, a empresa quer poder escalar o front-end sem interromper o back-end (e, novamente, evitar latência). Mudar para um provedor de nuvem colocalizado significa que eles podem fazer isso, porque a nuvem está ali, em uma interconexão muito rápida, de nível de data center.

Independentemente da abordagem para a nuvem (co-lo ou pública), a chave para uma migração bem-sucedida para a nuvem é migrar o máximo possível da arquitetura. Não obstante as opções de serviço em nuvem, é importante manter serviços de aplicativos críticos com seu aplicativo durante sua transição para garantir que o desempenho e a segurança não sejam comprometidos pela realocação. 

*Também conhecida como Lei de Hoff , que, embora não seja realmente uma lei, continua sendo uma observação tão precisa hoje quanto quando foi observada pela primeira vez em 2009.