Migração Modernizada para a AWS

Published in

BRLink

10 min readOct 5, 2023

Autores

Introdução

Toda organização passa por momentos de inflexão em tomadas de decisões estratégicas, que potencialmente vão influenciar todo o rumo que a empresa tomará dali em diante. A depender das decisões feitas Donee os caminhos seguidos por decorrência delas, essas organizações podem usufruir de muitos benefícios ou sofrer prejuízos (potencialmente irreversíveis).

Um ponto de inflexão, que ocorre periodicamente, é quando uma organização necessita decidir qual o caminho irá seguir quando o assunto é inovação, tecnologia e infraestrutura. Não muito raro, algumas organizações optam por seguir caminhos conhecidos, que são de manter a infraestrutura que possuem ou então fazem uma pequena atualização que possibilita prolongar a vida útil do negócio no curto prazo. Essa abordagem é o caminho mais seguro e conhecido, entretanto o mais limitante.

Entretanto, existem cenários onde organizações realizam um “salto de fé” e buscam modernizar suas estruturas ou migrá-las para ambientes novos, como a nuvem. Nesse artigo iremos acompanhar a história da Empresa X, um case privado de como uma organização optou por migrar sua infraestrutura para a nuvem, usando do potencial da AWS para ter a melhor estrutura para atender às suas necessidades.

Dor de Negócio

A Empresa X se viu em um momento estratégico para a mudança do seu modus operandi em termos de infraestrutura. Isso ocorreu devido ao término da vida útil da sua infraestrutura on-premise (estrutura de servidores própria). Ao analisar o dimensionamento feito e a utilização real da infraestrutura, a Empresa X percebeu que fez um grande investimento (mais que o necessário) e ainda assim teve que trocar a sua estrutura para uma mais atualizada. Nesse caso, todos os servidores e recursos defasados seriam dados como investimento perdido, por não ser possível reaproveitá-los para outros fins. Finalmente, a Empresa X percebeu que precisava de uma estrutura que fosse escalável, altamente disponível e que minimizasse o “desperdício” de processamento.

Solução

Dessa forma, não querendo repetir erros do passado, a Empresa X optou por migrar a sua estrutura para um modelo de negócio em que ela não tenha que se preocupar com a compra de hardware para comportar seus workloads. Assim, a Empresa X buscou na AWS um provedor de nuvem e na BRLink um parceiro nessa migração.

A solução proposta pela AWS foi a aplicação do MAP (Migration Acceleration Program) para agilizar e estruturar esse processo de migração com o apoio de um parceiro qualificado. Dentro do MAP, o processo é dividido em 3 etapas, sendo elas o Assessment, Mobalize e Migrate & Modernize. No processo da Empresa X, a BRLink realizou a etapa de Assessment até o momento presente, aguardando apenas o direcionamento de negócio para a evolução ao Mobalize.

MAP Assessment

Nessa primeira etapa do MAP, o Assessment, o parceiro realiza uma análise inicial dos ambientes atuais do cliente, visando a migração para a nuvem AWS. Durante essa análise, a BRLink buscou reuniões de levantamento de requisito técnicos e de negócio com a Empresa X, buscando conhecer profundamente os direcionais e objetivos da mesma. Os insights levantados nessa etapa fornecem insumos para tomadas de decisões estratégicas em termos de arquitetura cloud. Esse processo foi dividido em etapas, que serão descritas a seguir.

Coleta de Agentes

Para analisar detalhes técnicos específicos da infraestrutura do cliente de maneira remota, a BRLink utilizou o Application Discovery Service (ADS) dentro do Migration Hub. A principal funcionalidade do ADS é a coleta de informações técnicas dos servidores onde o agente é instalado. Ao armazenar os dados no Migration Hub, o ADS permite uma visualização das propriedades técnicas e de uso das máquinas, além de recomendações de instâncias EC2 (Elastic Compute Cloud) e visualização dos relacionamentos dos servidores. Toda a coleta foi realizada ao longo de algumas semanas, a fim de ter uma visualização mais profunda do uso das máquinas no cotidiano da Empresa X.

Migration Readiness Assessment

Durante o período de coleta de informações do ADS, a BRLink utilizou o Migration Readiness Assessment Tool (MRA Tool) para mensurar a maturidade da Empresa X para essa migração à AWS. O MRA Tool é uma ferramenta que provê um roteiro de questionamentos técnicos e de negócio para empresas com intenção de migrar para a AWS. Nesse questionário, são abordados temas como conhecimento técnico, características da infraestrutura atual, cultura da empresa, comunicação interna e externa, hábitos de documentação de processos e comprometimento dos stakeholder e áreas envolvidos no MAP.

O formato recomendado dessa reunião pelo MRA Tool acaba sendo inviável, pela necessidade de reunir os membros C-Level e/ou stakeholders impactados pelo MAP por uma agenda extensa (pelo menos 6 horas). Na experiência com outros clientes da BRLink, foi percebido que reservar um tempo longo dessas pessoas para o preenchimento do MRA Tool gera problemas de logística e engajamento, visto que nem todos os temas do MRA envolvem todas as áreas da empresa. Assim, contornando esse percalço, a BRLink dividiu as questões do MRA em sessões de bate-papo mais direcionadas a temas específicos, deixando de ser um simples preenchimento de formulário para se tornar um bate-papo com as áreas. Dessa forma, apenas as áreas específicas (Segurança, Redes, Dados, Processos, Negócios, etc) são envolvidas em sessões mais curtas de até uma hora.

Durante o MRA da Empresa X, algumas informações vitais foram levantadas e mapeadas na arquitetura de referência, sendo elas:

Localização geográfica carente de infraestrutura de ponta. Não possuíam acesso a um link dedicado maior que 150Mbps;
Pouco ou nenhum conhecimento sobre computação da nuvem;
Operações na Empresa X eram feitas de forma manual, como por exemplo o backup das informações que eram feitos em fita e armazenados em um cofre na empresa;
Não possuíam processos e procedimentos documentados, como por exemplo runbooks;
Hardware próximo ao seu EOL (End Of Life).
Todas as aplicações críticas, que eram 4 ao todo, eram sustentadas pelo que chamavam de “parceiros de negócio”, ou seja, eles dependiam de outras empresas para dar sustentação nos ambientes em produção;
Uma dessas aplicações críticas ficava no chão de fábrica, passando por um processo de atualização de software;
Havia uma iniciativa embrionária de Big Data utilizando ferramentas de visualização de dados em dashboards;
Stakeholders interessados em adquirir mais conhecimento sobre nuvem AWS através de workshops;
Possuíam uma gama de informações sendo consumidas de forma analíticas em banco transacional on-premise.

Com a coleta de informações de forma dinâmica, o time de especialistas da BRLink analisa as gravações e anotações feitas para o preenchimento do MRA Tool, sem onerar o time C-Level do cliente nesse processo. A saída gerada pela ferramenta traz insights sobre a maturidade da Empresa X, além de direcionamentos para etapas de Mobalize e Migrate & Modernize.

Estratégias de Migração

Uma vez coletadas as informações da Empresa X, o próximo passo do processo de Assessment foi definir uma estratégia de migração para cada workload, tendo em mente que não existe uma regra única para todo cenário. Existem fatores que influenciam nessa decisão, como:

Criticidade do workload em produção: o quão vital é o workload para o funcionamento da Empresa X?
Compatibilidade com infraestrutura na nuvem: existem recursos na nuvem para comportar o workload sem necessidade de remodelagem do mesmo?
Nível de conhecimento: a Empresa X sabe operar o(s) serviço(s) que vão compor o workload na nuvem? Se não, ela consegue desenvolver sua equipe em tempo hábil?
Custo: o workload na nuvem terá um custo inferior, superior ou igual ao custo on-premise?

Assim, existem 7 estratégias de migração pensando em casos variados a depender da resposta para as perguntas acima, conhecidas como os 7 Rs:

Relocate: essa opção é válida para cenários onde uma aplicação pode ser realocada para a nuvem AWS, como casos de VM por exemplo.
Rehost: nesse caso, a aplicação passa por um processo de ser reinstalada na nuvem AWS, sendo passível de configurações e deploy.
Replatform: outro cenário viável é a troca da infraestrutura que suporta a aplicação, mudando assim sua plataforma para algo mais compatível na nuvem.
Repurchase: existem casos, onde soluções prontas SaaS (Software as a Service) podem ser utilizadas para substituir workloads sendo migrados. Nesse caso também é passível de um setup da estrutura nova.
Refactor: quando a aplicação não atende bem às necessidades ou é passível de ser reestruturada para tirar melhor proveito da nuvem, essa é a estratégia de migração ideal, refatorando todo o workload.
Retain: em cenários onde o custo-benefício da nuvem não justifica a migração, podemos optar por manter a estrutura como está e apenas conectá-la devidamente ao ambiente AWS.
Retire: finalmente, aplicações pouco utilizadas ou cuja criticidade de negócio não existe em nenhum nível podem ser facilmente descartadas para evitar gastos desnecessários.

No caso da Empresa X, a BRLink avaliou os fatores descritos para definir um possível destino para cada workload, classificando assim os mesmos em 3 níveis de risco (Alto, Médio e Baixo). Assim, os principais motivadores para as decisões foram:

Alto Risco

Sistemas operacionais defasados
Sistemas de PABX
Sistemas de CFTV
Sistemas de balanças de pesagem em larga escala
Print Servers
Sistemas de chão de fábrica que estavam em processo de atualização de software

Médio Risco

Sistema de câmeras com S.O. defasado, passível de substituição por uma arquitetura mais moderna com Data Lake
Sistema que possuía serviço gerenciado equivalente na AWS, sendo necessário um aprofundamento de estudos para definir a melhor estratégia nos 7 Rs
Sistema sustentado por parceiro e que, aparentemente, só daria suporte completo se migrassem para um Data Center do próprio parceiro

Baixo Risco

Alta integração com a AWS
Banco de Dados que compatíveis com o Relational Database Service (RDS)
Sistema com forte sugestão de modernização trocando o SO para opções sem custo de licença
Sistema utilizado para armazenamento de objetos e que poderiam ser facilmente direcionados para o Simple Storage Service (S3)

Depois dessa análise, o ambiente da Empresa X teve sua estratégia inicial de migração definida, sendo preparada para uma validação mais profunda na etapa do MAP Mobalize, onde ambientes piloto definidos no Assessment (levantando exemplos de cada cenário) foram selecionados para essa validação prática. O princípio dos pilotos de ambientes é criar uma jornada de migração “hands-on” para que a curva de aprendizado dos profissionais da Empresa X seja amenizada no processo.

Planejamento da Arquitetura

Definidas as estratégias de migração, a BRLink montou um diagrama de referência da arquitetura da Empresa X, visando dois cenários:

Migração “as-is”: manter as estruturas fundamentais da Empresa X, preservando suas características e apenas adicionando funcionalidades desejadas com urgência pela Empresa X.
Modernização: atualização das estruturas para um modelo de negócio mais escalável, tirando melhor proveito do potencial da nuvem.

Arquitetura as-is

Nessa versão inicial, o ambiente on-premise é “replicado” para a nuvem sem muito esforço ou modernização. Os workloads em VMs on-premise são levados para instâncias de Elastic Compute Cloud (EC2), mantendo seus ambientes e realizando as conexões pelo Direct Connect com os workloads retidos no cenário on-premise. Cada instância possui seu Elastic Block Storage (EBS) associado como volume de disco. Foi levado em consideração apenas uma Zona de Disponibilidade (AZ) por ambiente e a segregação de desenvolvimento, homologação e produção. As rotas de DNS foram direcionadas ao Route53 e os certificados guardados no Certificate Manager. A vantagem dessa arquitetura é o tempo de implantação reduzido, mas a desvantagem é o baixo uso do potencial das estruturas AWS.

Modernizada

Visando tirar esse melhor proveito da AWS, a BRLink apresentou à Empresa X uma arquitetura modernizada para seus workloads e necessidades. Nesse cenário, o ambiente de produção foi segmentado em múltiplas AZs para ter uma alta disponibilidade dos recursos alocados. Um Application Load Balancer distribui as demandas para réplicas das aplicações em diferentes AZs. O AWS Backup realiza as cópias de snapshots das aplicações e discos, salvando-as no Backup Vault. Os ambientes de QA (homologação) e desenvolvimento foram temporizados por alarmes que ligam e desligam os mesmos dentro do horário comercial, não havendo necessidade da disponibilidade fora dessa janela pelas regras de negócio da Empresa X. Todo o controle de acesso passa a ser realizado pelo Single Sign-On (SSO). O File Server passa a ser feito pelo FSx e os bancos de dados transacionais e relacionais passam para o AWS RDS. Finalmente, os dados analíticos são direcionados a um Data Lake.

Total Cost of Ownership (TCO)

Por não ser um case público, não podemos entrar nos detalhes de custos desse processo da Empresa X, entretanto, sumarizando em percentuais, a arquitetura “as-is” da Empresa X já trouxe um custo de sustentação estimado esperado pelos stakeholders. Ao aplicar as regras de modernização e melhores práticas da nuvem, a BRLink propôs uma arquitetura com uma redução de custos de 39.52%. Ainda assim, com um passo a mais, foi proposta uma arquitetura com reserva de instâncias de 1 ano para EC2 na arquitetura modernizada, gerando uma redução de 9.09% do custo dessa. Finalmente, a reserva de 3 anos das mesmas instâncias trouxe uma redução de 3.55% dos custos relativo às reservas de 1 ano.

Benefícios

Ao optar pela migração para a AWS, a Empresa X atinge novos níveis de maturidade de arquitetura das suas aplicações, trazendo alta disponibilidade para seus serviços, backup de máquinas e discos, aplicando regras automáticas para ligar e desligar ambientes exclusivos em horário comercial, boas práticas de gestão de acesso, entre outras. Ao optar por trazer a BRLink como parceiro, a Empresa X recebeu propostas de arquiteturas modernizadas e mais ajustadas às suas necessidades, possuindo uma redução de custos de até 46.97% de uma simples migração “as-is”.

Conclusão

Em momentos de inflexão nas tomadas de decisões estratégicas quanto a infraestrutura da empresa, os stakeholders devem considerar as alternativas mais apropriadas de acordo com os direcionamentos de negócio da organização. Ao optar por analisar uma estrutura em nuvem AWS, onde a empresa não possui conhecimento suficiente para realizar a melhor análise, a participação de um parceiro na migração é fundamental. A AWS possui um programa de aceleração de migração (MAP) que não apenas organiza a migração em fases, como direciona um parceiro com habilidades necessárias para prover as melhores práticas da nuvem!