A migração de aplicações para nuvem pode trazer redução de custos, mais produtividade, mais segurança, resiliência, melhor time-to-market dentre outros benefícios. A ideia deste post é servir a você como uma guia dos principais recursos para facilitar a migração de suas aplicações para a nuvem.
Nos dias de hoje é cada vez mais comuns as startups e novas empresas de tecnologias começarem 100% na nuvem, e aplicações nascerem utilizando recursos nativos de cloud como serverless, por exemplo.
Em contra-partida, mesmo em 2019, a vasta maioria das aplicações ainda roda on-premisses e a há muito espaço para o crescimento da computação em Nuvem.
O termo on-premises usado nesse post, que também é usado como on-premise e abreviado como on-prem diz respeito as cargas de trabalho (workloads, softwares, aplicações, funções) que são executadas em seus próprios servidores físicos em vez de serem executados na nuvem pública (AWS, Google Cloud, Azure, etc.).
Minha história de Migração para Nuvem
Lembro-me como se fosse hoje, quando decidimos que era hora de migrarmos nossos servidores para a Nuvem.
Era um dia como outro qualquer, no ano de 2011, tudo estava bem, e estávamos desenvolvendo novas funcionalidades em nosso Sistema SaaS para os clientes do varejo, quando descobrimos que todos os nossosservidores estavam fora do ar.
Deixa eu te dar um pouco mais de contexto…
Desde o seu nascimento em 2000 a empresa trabalhava no modelo de Software como Serviço.
Os nossos clientes em vez de comparem licenças e instalarem em seus próprios servidores como acontecia com as principais fornecedoras de sistemas, apenas pagavam para nós uma mensalidade que já incluía o custo dos servidores, o aluguel do data-centers, e todos os outros custos envolvidos na operação.
Os clientes simplesmente pagavam uma mensalidade e tinham o software disponível para ser usado através da Internet.
A nossa empresa que comprava os servidores e instalava em um data-center num modelo de collocation.
Basicamente contratávamos um aluguel de espaço para instalar nossos servidores no data-center, e cuidávamos dos upgrades de hardware, backups, comprávamos as licenças, aplicávamos os patches de segurança, reciclávamos os discos rígidos e o de todo o resto.
Naquele dia, todos esses nossos servidores ficaram fora do ar!
Rapidamente descobrimos que muitos outros sites e serviços famosos da Internet também estavam fora.
Quando finalmente conseguimos falar no data-center descobrimos que havia acontecido um incêndio e tudo havia sido desligado por segurança.
Nesse momento mil coisas passaram por nossas cabeças: será que nossos servidores podem ter sido comprometidos pelo incêndio? Será que perdemos dados? Como faremos para disponibilizar o sistema novamente para os clientes o mais rápido possível?
Bem, já ainda não conseguíamos entrar no data-center, pensamos em começar a nos preparar para ter que recomprar todos os equipamentos e restaurar os backups, então fomos cotar com os fornecedores de hardware.
A má notícia, é que nos prometeram que se fosse muito, mas muito urgente mesmo, conseguiriam nos entregar os novos equipamentos em 20 dias úteis.
20 dias úteis!
Isso é muito mais do que um cliente nosso poderia esperar…
Naquele momento percebemos o tamanho da fragilidade que tínhamos.
Mesmo com recursos para recomprar todos os equipamentos, estávamos correndo o risco de ficar por dias sem serviço, porque não conseguíamos os servidores à pronta entrega.
A boa notícia é que em poucas horas, tudo estava novamente no ar, nada havia acontecido com nossos servidores, nenhum dado foi perdido, e os clientes não foram prejudicados (tirando o fato de terem ficado algumas horas sem sistema).
Depois dessa história toda, decidimos que jamais queríamos passar por uma situação como essas novamente e não queríamos mais estar expostos a este tipo de risco.
E foi aí que a AWS fez total sentido para nós.
Em poucas semanas, começamos uma grande parceria que dura até hoje, e migramos tudo para lá, sem exceção.
O primeiro passo foi fazer o famoso “lift and shift“.
Migramos os web servers para servidores EC2 e os bancos de dados para servidores RDS já com garantia de backups automáticos, Multi-AZ, de forma que se um datacenter (AZ) tiver um problema e sair do ar, outro a cerca de 100km de distância continuaria servindo nossas aplicações com indisponibilidade zero ou muito baixa.
Em poucos meses já estávamos nos beneficiando de outros serviços como S3 para armazenamentos de conteúdo estático e arquivos, SQS para mensageria, SES para envio de e-mails, e muitos outros (naquela época a AWS tinha bem menos serviços do que hoje, mas ainda assim foi um novo universo de possibilidades que se abriu para nós).
Melhoramos muito a segurança, escalabilidade e resiliência dos nossos serviços e aplicações. E agora podemos dormir tranquilos a noite.
Atualmente, quando fechamos um novo contrato e precisamos de mais infra-estrutura, em vez de esperar semanas até os servidores novos chegarem e serem instalados no data-center, em minutos executamos um processo totalmente automatizado que provisiona toda a infra-estrutura necessária na nuvem com custo mais otimizado e arquitetura mais segura, escalável e resiliente do que era antes.
Essa foi a história da minha empresa, mas sem dúvida você pode construir uma história assim na sua.
Não importa se você desenvolve e fornece software para outras empresas usarem, ou se hospeda os softwares on-premisses de fornecedores externos para usuários da sua empresa. Tenho certeza de que a Nuvem poderá abrir um novo universo de possibilidades e tornar seu negócio mais ágil e resiliente.
Estratégias de Migração para a Nuvem
Para cada um de suas aplicações, de uma forma ou de outra, você vai acabar adotando alguma das seguintes estratégias:
Rehost (“Lift and Shift”): a estratégia mais comum e uma das rápidas, onde basicamente movem-se os servidores como eram no data-center para a nuvem. Basicamente cada servidor que você tinha no seu data-center vai se tornar um servidor EC2 na AWS. Essa estratégia apesar de rápida, e poder ser usada como um primeiro passo de migração, não aproveita muito do potencial e escalabilidade, elasticidade e otimização de custos que a Nuvem oferece.
Replatform (“Lift and Reshape”)”: nessa estratégia você move os recursos para AWS, porém muda a plataforma para serviços mais gerenciados aproveitando melhor os serviços da nuvem. Por exemplo, em vez mover um servidor de MySQL para EC2, você move para RDS MySQL que é gerenciado pela AWS, tem redundância automatizada (MultiAZ), backups automáticos, etc. Ou exemplo seria mover um cluster de MongoDB para o DocumentDB (que é basicamente um MongoDB gerenciado).
Re-Comprar (Drop and Shop): abandonar o atual e comprar um novo, isso é muito comum quando você, por exemplo, desiste de um CRM Client/Server que rodava no seu data center para usar o SalesForce na AWS.
Re-Projetar: tipicamente, isso é impulsionado pela forte necessidade que a empresa tem de adicionar recursos, escala ou desempenho que seriam, de outra forma, difíceis de alcançar no ambiente on-premisses. Isso acontece, por exemplo, quando você transforma sua aplicação para Serverless usando AWS Lambda. De todas as estratégias essa a que tem maior custo de migração, mas muitas vezes, será também a que poderá oferecer mais oportunidades de otimização de recursos de infra-estrutura.
Aposentar (Retire): desistir de uma aplicação que não é mais necessária ou não gera mais valor para a organização.
Retain (Reter): manter como está por enquanto, e reavaliar no futuro.
Estágios de adoção da nuvem
Na maioria das vezes as empresas não fazem uma grande migração de todas as suas aplicações de uma vez para a nuvem.
Cada empesa tem necessidades específicas e naturalmente terá uma jornada de adoção e migração para a nuvem diferente. Segundo a AWS, é comum que as empresas passem por essas quatro etapas:
Projeto: Nessa primeira fase você escolher um projeto-piloto para testar, sentir-se mais familiarizado e conhecer, na prática, alguns benefícios da nuvem.
Base: Depois de vivenciar os primeiros benefícios da nuvem, você cria a base para escalar sua adoção da nuvem. Define os padrões, as regras de segurança, treinas as pessoas, forma o time cross-funcional para guiar a transição da organização (CCoE – Centro de Excelência em Nuvem).
Migração: Nesta fase, finalmente são migradas as aplicações, especialmente na estratégia “Lift-and-Shift“.
Reinvenção: Agora que suas operações já estão na nuvem, você pode se concentrar na reinvenção aproveitando a flexibilidade e os funcionalidades que a nuvem te oferece, escrevendo e redesenhando arquiteturas e aplicações.
Frameworks de Apoio
O Cloud Adoption Framework (CAF) foi criado pela equipe de professional services da AWS para te ajudar a formar um plano de migração para a nuvem considerando não apenas a tecnologia por si só, mas também os diversos impactos na organização, no negócio, nas pessoas, na governança, na segurança e em outros aspectos importantes.
Existe também o The Open Group Architecture Framework (TOGAF) é um framework de arquitetura corporativa que oferece uma abordagem global para design, planejamento, implementação e governança de uma arquitetura corporativa. É um dos frameworks mais utilizado pelas maiores empresas (Fortune 500). O TOGAF apresenta o Architecture Development Method (ADM), que descreve um processo de diversas fases para gerenciar o desenvolvimento de uma arquitetura empresarial.
Arquiteturas Híbridas
Um arquitetura híbrida permite que você misture recursos em nuvem com recursos on-premisses.
É uma abordagem bastante comum, especialmente no início da adoção de nuvem quando a organização ainda está adquirindo know-how e experiência na nuvem.
Nesse caso a nuvem se torna uma extensão natural da plataforma on-premisses para projetos pilotos e novos projetos.
É possível, por exemplo que uma aplicação que roda on-premisses tenha seus backups armazenados no S3.
Empresas utilizam VMware podem criar arquiteturas hibridas com bastante facilidade através do VMWare vCenter.
Ferramentas de Migração
Migração de Dados
AWS Import/Export: Permite que vocêr renvie um Drive Externo para a AWS que então será recebido pela AWS e copiado para o S3. Dados podem ser criptografados.
AWS Snowball: Você recebe da AWS um dispositivo que permite copiar até 80TB de dados e enviar de volta para a AWS que disponibilizará os dados na sua conta através do S3. Dados podem ser criptografados.
AWS Snowmobile: é literalmente um caminhão que permite que você copie até 100PB de dados para serem migrados para a AWS. Parece brincadeira, né? Mas não é… Veja o vídeo para conhecer um case real:
AWS Storage Gateway: É um serviço de armazenamento híbrido que permite que aplicativos on-prem usemo armazenamento na Nuvem AWS. Você pode usar o serviço para backups, recuperação de desastres, processamento de dados, ou migração.
Você pode conectar ao serviço por meio de uma máquina virtual ou um dispositivo de gateway de hardware usando protocolos de armazenamento padrão, como NFS, SMB e iSCSI. O gateway é ao S3, Glacier, e EBS e AWS Backup.
Database Migration Service (DMS): é um serviço que ajuda você a migrar bancos de dados para a AWS de modo rápido e seguro. O banco de dados de origem permanece totalmente operacional durante a migração, minimizando o tempo de inatividade de aplicativos que dependem do banco de dados.
Schema Conversion Tool (SCT): O DMS permite que você migre de um banco de dados para on-premiesses para o mesmo tipo de banco de dados na nuvem (ex: de Oracle para Oracle), mas também permite que você migre de um tipo de bancos de dados para outro (ex: de Oracle para Aurora) e para fazer a conversão dos tipos de dados e scripts de criação de tabelas e conversão de dados, utiliza o SCT que faz a transformação do código do banco de origem para o banco de destino.
Veja no vídeo abaixo um estudo de caso da Verizon sobre migração de dados para Nuvem:
Não deixe de ler também este artigo que te ajudará a escolher o melhor banco de dados em nuvem a depender das características da sua aplicação.
Migração de Servidores
AWS Server Migration Service (SMS): este é um serviço que facilita e agiliza a migração, automatizando, coordenando migrações de servidores on-premisses para nuvem da AWS. Suporta máquinas virtuais VMware vSphere e Microsft Hyper-V/SCVMM, permitindo sincronização de volumes e criação de snapshots.
Application Discovery Service: este serviço coleta dados sobre o seu ambiente on-premisses, e apresenta dados de configuração, uso e comportamento dos servidores para ajudar a compreender melhor as cargas de trabalho atuais antes de migrar. Você pode usar esses dados para estimar o custo total de propriedade (TCO) da execução na AWS e planejar a migração. Além disso, esses dados também ficam disponíveis no AWS Migration Hub (falaremos sobre ele a seguir), para facilitar o processo de migração os servidores descobertos e rastrear o progresso de sua migração para a AWS.
AWS Migration Hub: esse serviço disponibiliza um único local para rastrear o andamento de migrações de aplicações entre várias soluções da AWS e de parceiros. O uso do Migration Hub permite escolher as ferramentas de migração da AWS e de parceiros que melhor atendam às suas necessidades, além de proporcionar visibilidade sobre o status da migração no seu portfólio de aplicativos. É totalmente integrado com o Database Migration Service (DMS), o Server Migration Service (SMS).
Migração de Redes
O primeiro passo é garantir que não há overlap (sobreposição) de blocos CIDR entre suas VPCs e rede on-premisses, por exemplo, se você está usando 192.168.0.1/16 na sua rede on-premisses certifique-se de não usar também na sua VPC.
Na AWS os seguintes IPs final (0, 1, 2, 3 e 255) são reservados em todas as subredes de VPC: ex: 192.168.0.0 (Network Address), 192.168.0.1 (VPC Router), 192.168.0.2 (DNS), 192.168.0.2 (Reservado), 192.168.0.255 (Reservado).
Leia meu post sobre Networking na AWS para aprender mais sobre o funcionamentos das VPCs e Subredes (Subnets) da AWS.
É possível criar VPNs entre sua rede on-prem e a a nuvem da AWS, contratar o Direct Connect para ter uma conexão direta com o backbone da AWS , e usar as duas coisas em conjunto através do protocolo BGP.
Conclusão
Não importa o volume de dados que sua empresa precisa suportar, o número de aplicações que possui, ou a complexidade de sua arquitetura. Atualmente, você tem a sua disposição frameworks e ferramentas que permitem que você migre suas aplicações para nuvem ou mantenha arquiteturas hibridas que usam a nuvem para expandir as capacidades de seu ambiente atual.
Tenha em mente que tecnologia não é tudo, um dos principais desafios numa migração para nuvem são as pessoas, a mudança cultural, a gestão de projetos, os treinamentos, e a mudança de mindset para uma nova forma que criar as aplicações para usarem os recursos disponíveis na nuvem como Serverless, por exemplo.
Para se aprofundar no tema de migração para a nuvem recomendo que leia os seguintes whitepapers:
- AWS Migration Whitepaper
- Migrating Applications to AWS
- Migration to AWS Best Practices and Strategies
- An Overview of the AWS Cloud Adoption Framework
- AWS Cloud Transformation Maturity Model
