Essa é uma pergunta recorrente no nosso dia a dia na Getup, há uma certa confusão sobre a necessidade ou não de efetuar modificações no código e na arquitetura do software para migrar e rodar na nuvem.
A resposta para essa questão poderia ser "depende", e não estaria errada.
Vamos supor que sua aplicação não passe no teste das 3 perguntas abaixo, mas você quer migrar assim mesmo pois, mesmo sua aplicação não sendo Cloud-Native, ainda existem benefícios a serem considerados (agilidade de provisionamento, melhorar a disponibilidade, terceirizar a gestão da infra, …). Então mesmo não alcançando todos os benefícios, neste caso ainda pode fazer sentido migrar na forma que está.
Cloud Native: 3 perguntas
Porém se você quer realmente tirar proveito de recursos Cloud-Native como escalabilidade automática, melhor ciclo de rollout e rollback de software, uso de CI/CD e ter um melhor retorno sobre investimento, então você precisa responder sim para as 3 perguntas abaixo.
Os dados estão separados do código?
As sessões de autenticação são guardadas de forma centralizada?
As configurações são guardadas usando envvar's?
Dados estão separados do código
Por dados eu me refiro a qualquer tipo de persistência. Você precisa separar os dados do código (imagens, uploads, pdf, …). Rodar em ambientes diferentes permitirá escalar a aplicação e distribuir o workload, melhorando a performance, confiabilidade do ambiente além de economia, permitindo provisionar recursos de forma dinâmica e apenas nos momentos necessários.
Uma opção muito comum é utilizar Object Storage para guardar persistência, por exemplo Amazon S3 ou Azure Blob Storage.
Sessões guardadas de forma centralizada
Uma das vantagens em levar uma aplicação para a nuvem está em poder escalar ou crescer horizontalmente e balancear a carga entre os servidores. Em um ambiente assim usuários podem, e provavelmente irão, cair em diferentes servidores.
Para evitar problemas de autenticação recomenda-se o armazenamento no browser, em um banco de dados ou memcache.
[Atualização] Contribuição TOP do Elton Minetto da Coderockr
Quando lançamos a nova versão do Planrockr nós optamos por outro caminho, o de não existir uma sessão de usuário. Estamos usando JSON Web Tokens e desta forma a aplicação fica ainda mais escalável e fácil de migrar para a nuvem, usar containers e atingir os 12 fatores.
Configurações por envvar
É prática comum o programador utilizar ambientes diferentes para desenvolver, testar e rodar sua aplicação. Cada ambiente tende a apresentar suas peculiaridades, como número de componentes distintos (banco, cache, caminho do storage) e configurações específicas — por exemplo, uma senha mais forte em prod do que em dev.
Pensando nisso, é importante que estas variáveis sejam facilmente alteradas, pois fazem parte da configuração do sistema.
Um aplicação escalável deve guardar estas configurações em variáveis de ambiente, e seus dados acessíveis em tempo de execução.
Bônus: Sua aplicação está com boa arquitetura?
Aplicações bem desenhadas e com bom código rodam bem em qualquer lugar. O mesmo vale para o contrário, se sua aplicação não possui uma boa arquitetura e possui gargalos de performance, considere resolver essas questões antes de levar para a nuvem, do contrário você só estará mudando o problema de endereço.
Exemplo de ferramentas que podem ajudar são Newrelic e Opbeat.
Certamente existem outros pontos a serem considerados, mas esses são os principais e um bom ponto de partida.