Multicloud: da migração à otimização de custos
Arquitetura multicloud e migração de serviços - Apresentação
Boas-vindas ao curso de Multicloud: da migração à otimização de custos. Me chamo Tony César e estarei ao lado de vocês durante toda essa jornada de aprendizado.
Audiodescrição: Tony se declara como um homem de pele morena, alto, com cabelo curto e usa óculos. Veste uma camiseta cinza lisa. Ele está nos estúdios da Alura, e ao fundo é possível ver uma estante com itens decorativos à sua direita com uma iluminação roxa e azul.
Para quem é esse curso?
Este curso é direcionado a pessoas gestoras e gerentes de TI, abordando uma ampla gama de tópicos relevantes para esse público.
Ao longo do conteúdo, exploraremos diversos recursos das plataformas AWS e Azure, mas é importante destacar que os conceitos e práticas discutidos são aplicáveis também ao Google Cloud Platform (GCP) e ao Oracle Cloud Infrastructure (OCI).
O que aprenderemos?
Aprenderemos sobre arquitetura multicloud, como várias nuvens trabalham entre si. Exploraremos a migração de serviços, como migrar um serviço do on-premise (local) para a nuvem, por exemplo. Sincronização e replicação de dados, que é muito interessante também. Resiliência e redução de latência, ou seja, como podemos trabalhar entre esses recursos.
Estratégia e análise para otimização de custos, como utilizar de forma otimizada cada recurso. Conformidade com a LGPD, ou seja, como organizar os dados da empresa, assim como estratégias de disastres e recovery também.
Aproveite os recursos da plataforma
Não deixe de aproveitar todos os recursos que a plataforma oferece! Além dos vídeos que serão assistidos, teremos atividades práticas, apoio no fórum e a comunidade no Discord, onde será possível obter ajuda e interagir com outros estudantes.
Conclusão
Contamos com a participação de todos para aproveitar ao máximo o conteúdo e a troca de experiências ao longo do curso!
Arquitetura multicloud e migração de serviços - Arquitetura inicial para alta disponibilidade
Nesta aula, abordaremos a situação da Zoop, um grande marketplace de vendas online que está enfrentando sérios desafios relacionados à disponibilidade de recursos.
Contextualizando o desafio
Os clientes tentam acessar a plataforma, mas se deparam com um site lento e dificuldades para completar o checkout, entre outros problemas. Como resultado, a empresa tem perdido clientes, o que impacta diretamente no faturamento. Diante desse cenário, a Zoop reconheceu a necessidade de reestruturar sua arquitetura de nuvem. Atualmente, a empresa utiliza apenas um provedor de nuvem, cuja configuração não está otimizada, o que pode ser causado por uma série de fatores.
Solução do desafio
Para solucionar esse problema, a Zoop adotará uma estratégia de multicloud, utilizando dois provedores de nuvem para garantir redundância e um funcionamento sincronizado, evitando interrupções no serviço.
Etapas
Passaremos por algumas etapas essenciais:
- Criação da arquitetura;
- Implementação das estratégias que serão adotadas;
- Seleção dos provedores de nuvem, Azure e AWS, para trabalharem em sincronia.
Analisando a estrutura atual
Analisaremos como está estruturada a arquitetura da Zoop atualmente:
A empresa optou por um ambiente multicloud, utilizando AWS e Azure. A arquitetura possui alguns recursos, mas não é tão complexa quanto se poderia imaginar para esse tipo de ambiente.
À esquerda, no início, pbservamos a pessoa usuária final, que acessa o site. Para a pessoa usuária final, todo esse processo é transparente. Ao acessar o site, a Zoop configurou seus recursos da seguinte forma: existem dois tipos de recursos. Na AWS, temos o AWS Route 53, e na Azure, o Azure Traffic Manager (DNS). Eles funcionam com direcionamento por DNS, alocando as pessoas usuárias conforme a necessidade, região e condições de rede, dividindo o tráfego e direcionando cada pessoa usuária para um tráfego diferente.
Mais à direita, encontramos o "AWS Load Balancer" na parte superior e o "Azure Load Balancer" na parte inferior, que operam de forma integrada, garantindo alta disponibilidade. Caso um dos balanceadores falhe, o outro assume automaticamente, evitando qualquer interrupção no serviço. Embora esses recursos estejam em nuvens diferentes, eles possuem funcionalidades muito semelhantes.
O Azure Load Balancer e o AWS Load Balancer são responsáveis por direcionar o tráfego para os servidores da Zoop, que possuem diferentes cargas de trabalho. Esses balanceadores de carga distribuem o tráfego de maneira eficiente, assegurando que, se um servidor ou balanceador parar de funcionar, o outro, independente da nuvem ou região, assuma o tráfego sem comprometer a continuidade do serviço.
A operação de ambos é praticamente idêntica, proporcionando redundância e resiliência no ambiente.
Essa é a jornada do cliente: essa pessoa acessa o site, e o AWS Route 53 ou o Traffic Manager direciona a pessoa usuária para a melhor rota. Se houver excesso de acessos a um servidor, tanto o Load Balancer da AWS quanto o da Azure trabalham em segundo plano para direcionar para a melhor máquina. Seguem-se os serviços críticos na AWS, como o AWS EC2, que são as máquinas virtuais na AWS.
Os serviços críticos nesses servidores podem incluir banco de dados, aplicações, entre outros.
Na Azure Load Balancer, temos o serviço de backup e failover do Azure App Service secundário, funcionando em tempo real. O Azure App Service pode estar rodando um site ou outra aplicação. Isso é aberto para que possamos imaginar como aplicar isso na realidade do dia a dia. Após passar pelos serviços críticos na AWS, segue para o AWS RDS, um serviço de banco de dados, que pode rodar SQL ou Postgre, dependendo da usabilidade da empresa.
Abaixo, temos o Azure Database for Postgre. No RDS, pode estar rodando um Postgre da AWS, enquanto no Database da Azure também está rodando um Postgre, garantindo redundância.
Por último, o AWS S3 realiza todo o backup do que está acontecendo, e o Azure Blob Storage também atua como backup para o ambiente. Este é um diagrama simples, uma arquitetura básica, mas importante, que demonstra como podemos ter um ambiente multicloud trabalhando com redundância.
Conclusão
Com essa arquitetura, a Zoop terá alta disponibilidade, resiliência e continuidade do serviço, sem interrupções. Não enfrentarão mais problemas críticos, como quedas ou lentidão, e os clientes não enfrentarão mais esses problemas. Questões de SLA estarão em perfeita ordem, garantindo que a Zoop não pare durante os serviços.
Arquitetura multicloud e migração de serviços - Migração de serviços e dados
A Zoop enfrentou um problema devido à complexidade do seu ambiente em nuvem, à configuração inadequada e ao uso excessivo de recursos. Por isso, optou-se pelo planejamento para o multicloud. No entanto, a Zoop, sendo um grande mercado com muitos anos de existência, mantém um ambiente On-Premise de grande porte, utilizado diariamente.
Contudo, é necessário migrar esse ambiente para a nuvem. Esse ambiente, por ter sido criado há muitos anos, não foi projetado para a nuvem. O grande desafio, portanto, é como migrar ambientes legados, que não foram pensados para a nuvem, para a nuvem.
Agora, será apresentado como dois recursos — um fornecido pela AWS e outro pela Azure — podem ser fundamentais para auxiliar na migração de serviços legados, ou de outros tipos de serviços, para a nuvem. Esses recursos possibilitam uma migração planejada, minimizando riscos e evitando problemas ao longo do processo.
Azure Migrate
Primeiramente, é importante destacar o Azure Migrate, ou Migrações para Azure, que é uma das principais ferramentas oferecidas pela Azure para a migração de recursos e serviços para a nuvem. Através do site da ferramenta, é possível acessar toda a documentação detalhada, onde estão descritos os principais recursos do Azure Migrate.
Essa ferramenta adota uma abordagem unificada para a migração e modernização para a nuvem, permitindo transferir os serviços e produtos legados para o ambiente em nuvem de forma estruturada. Além disso, ela já realiza a adequação dos recursos da nuvem Azure durante o processo, facilitando a transição e a adaptação dos sistemas.
Na documentação, é possível encontrar uma introdução completa, além de um guia passo a passo para implantar e conectar todos os recursos, permitindo que cada um siga as etapas de acordo com a realidade e as necessidades específicas do seu ambiente.
AWS Migration Hub
Além disso, também temos o AWS Migration Hub, que oferece funcionalidades semelhantes às do Azure Migrate, com algumas diferenças sutis, ajustadas às particularidades de cada organização.
Assim como no Azure Migrate, no AWS Migration Hub é possível acessar uma visão geral dos recursos, explorar os benefícios específicos conforme o tipo de migração que será realizado, e consultar casos de uso que ilustram como a migração foi realizada em diferentes contextos.
Na seção "Explorar recursos AWS Migration Hub", o portal também permite que vocês aprofundem o conhecimento e comecem a explorar detalhadamente cada um dos serviços oferecidos.
O site ficará disponível para que possam acessar ambas as ferramentas e explorar a documentação, permitindo entender como cada uma delas pode ser aplicada de forma mais adequada ao seu ambiente.
O papel da equipe de TI
Agora que já conhecemos as ferramentas de migração, tanto da Azure quanto da AWS, e sabemos de sua existência, esse é um passo importante. Porém, é essencial entender o papel do time de TI da Zoop nesse processo. Não se trata simplesmente de pegar as ferramentas e realizar a migração de maneira aleatória — isso pode ser muito arriscado.
É fundamental que haja um planejamento detalhado sobre o que será migrado e como será feito esse processo. A migração deve ser feita de forma estratégica, em fases, ou até mesmo de uma vez, dependendo da realidade de cada empresa.
Estamos lidando com programas legados e serviços que podem ser migrados, mas, dependendo da empresa, pode haver a decisão de não migrar tudo. Alguns serviços podem ser mantidos no ambiente On-Premise, o que é perfeitamente aceitável. Para isso, o time de TI da Zoop deve realizar uma auditoria minuciosa para identificar o que realmente precisa ser migrado e o que pode permanecer local.
Estratégia de migração
Com base nessa análise, a migração deve ocorrer de forma gradual, começando pelos serviços mais simples e fáceis e, posteriormente, avançando para os mais críticos.
Serviços mais fáceis de migrar
Serviços mais fáceis de migrar podem variar dependendo da empresa. No contexto da Zoop, podemos considerar aplicações web internas com baixa criticidade. Isso inclui, por exemplo, aplicações IaaS, sites estáticos ou sistemas de intranet, que são mais fáceis de migrar e apresentam menor risco de causar problemas.
Também existem serviços de batch não críticos, como aqueles automatizados via batch ou Cron no Linux. Esses serviços, que operam diariamente, podem não ser considerados críticos em termos de impacto imediato, mas, devido à automação mais antiga, vale a pena migrá-los para um recurso da nuvem mais adequado.
Serviços de desenvolvimento e teste também podem ser migrados. Para os times de pessoas desenvolvedoras, teste e homologação, a migração não causará problemas.
Em suma, são:
- Aplicações web internas com baixa criticidade;
- Serviços batch não críticos;
- Serviços de desenvolvimento e teste.
Já aprendemos que a migração deve ser planejada e realizada por etapas. Após passarmos pelos serviços que não são críticos, agora abordaremos os serviços que exigem mais atenção durante a migração.
Serviços que precisam de mais atenção
Bancos de dados transacionais críticos
Os bancos de dados transacionais críticos, como os utilizados em sistemas de gestão, geralmente incluem bancos como o Oracle, MySQL, entre outros, que fazem parte de ambientes legados e necessitam de migração.
Por serem utilizados diariamente, esses bancos de dados exigem uma atenção especial durante o processo de migração. É fundamental planejar a janela de migração — se será realizada durante um fim de semana, na madrugada, ou em outro momento adequado — e garantir que os times responsáveis estejam disponíveis para dar suporte durante a migração.
Aplicações delgadas com muitas dependências
Muitas aplicações atualmente possuem grande dependência de diversos outros serviços dentro da empresa. Por exemplo, o banco de dados pode ser central para várias aplicações que dele dependem. Ou uma aplicação principal pode precisar de vários serviços conectados a ela para obter e liberar atualizações. Essas aplicações demandam muita atenção durante a migração.
Serviços que exigem alta disponibilidade
Serviços que exigem alta disponibilidade, como os dois serviços que mencionamos anteriormente. O banco de dados, que não pode parar, e as aplicações que têm uma dependência muito grande de outros serviços. Eles não podem parar logo, precisam de alta disponibilidade.
Dados financeiros e sensíveis são migrados em fases
Agora, abordaremos a migração de dados financeiros e sensíveis, que deve ser feita em fases. Esse processo gradual já foi mencionado ao longo deste tópico de migração. A razão para isso é que não podemos migrar tudo de uma vez. No entanto, é importante ressaltar que a abordagem depende da realidade específica de cada empresa.
Monitoramento e validação
Monitoramento e validação são fundamentais nesse processo. Vamos entender alguns deles a seguir.
Monitoramento de falhas
É necessário implementar um sistema de monitoramento de falhas, utilizando ferramentas como Grafana, Zabbix ou qualquer outra que seja mais adequada à realidade da empresa.
Esse monitoramento permite agir de forma proativa assim que um problema for identificado, evitando a situação em que a equipe só toma conhecimento de uma falha quando o sistema já parou, gerando a necessidade de correção emergencial após um atraso de uma ou duas horas.
Teste pós-migração
O teste de pós-migração é uma etapa crucial no processo. Suponhamos que a janela de migração seja de três dias. Após concluir a migração e garantir que os serviços, recursos e servidores foram transferidos corretamente, é necessário realizar os testes de pós-migração.
Isso envolve verificar se todos os serviços estão funcionando como esperado, com a participação das pessoas-chave que utilizam diariamente os serviços migrados.
Durante essa fase, todos os testes possíveis devem ser executados para validar se o sistema está operando corretamente. Se tudo estiver funcionando adequadamente, a próxima etapa é o monitoramento contínuo.
Backups e redundâncias
Backup e redundância são essenciais para garantir a continuidade e segurança dos dados. Esse ponto está relacionado diretamente ao teste pós-migração.
Por exemplo, no caso da redundância, após a migração, podemos interromper um serviço para verificar se o serviço redundante é ativado corretamente. Quanto ao backup, após realizá-lo, podemos remover um item histórico e verificar se o backup é restaurado corretamente. Esses testes são válidos e devem ser parte do planejamento. É importante elaborar um cronograma detalhado, passo a passo, para evitar problemas durante o processo.
Quanto aos riscos? Como ficam os riscos nessa situação?
Riscos
Perda de dados
A perda de dados é um risco relevante. Por isso, é necessário estar atento tanto à origem quanto ao destino. Precisamos saber exatamente o que será transferido e garantir que todos os dados sejam migrados 100% corretamente. Além disso, é fundamental ter um planejamento de rollback, ou seja, uma estratégia para que, caso a migração não funcione como esperado, tudo possa ser revertido ao estado anterior.
Interrupção de serviço
Suponhamos que um serviço tenha sido interrompido. E agora, o que fazer? Há um monitoramento? E se ele foi interrompido porque falhou e não há um backup? E agora, o que fazer? E se a interrupção aconteceu devido a algum problema no recurso, em uma região específica? E então, o que fazer se não há redundância? Portanto, isso deve ser levado em consideração.
Compatibilidade e dependências
O recurso A será compatível com o recurso B? Esse tipo de dúvida costuma estar relacionado ao conceito de interoperabilidade. Embora o termo seja um pouco técnico, ele é bastante utilizado e se refere à capacidade dos recursos se comunicarem e trabalharem em conjunto. Ou seja, sistemas precisam ser capazes de interagir entre si de forma eficaz.
Da mesma forma, as dependências entre os recursos precisam ser avaliadas: a dependência que existia em um contexto continuará existindo de forma adequada no novo contexto? Esse aspecto também precisa ser cuidadosamente considerado.
Agora, vamos falar sobre os custos.
Custos
Quando migramos serviços e recursos para a nuvem, é importante considerar que o custo na nuvem tende a aumentar. Isso acontece porque, ao utilizar um ambiente de nuvem, há um custo médio mensal que já inclui todos os recursos alocados, com os quais você acaba se acostumando.
No entanto, à medida que novos recursos são movidos para a nuvem, o custo pode crescer. Esse aumento é normal, mas é preciso estar atento a ele para garantir que os custos sejam gerenciados de forma eficiente.
Ferramentas de migração
Então, é necessário verificar se as ferramentas que utilizaremos para a migração vão impactar no custo. É possível obter o preço de cada uma dessas ferramentas, alocar esse valor e ter uma previsibilidade para evitar surpresas. Além disso, não podemos esquecer do custo relacionado ao time de TI.
Mas por que o custo do time de TI é relevante? E se a equipe precisar trabalhar no final de semana? Nesse caso, haverá custos adicionais, como horas extras ou banco de horas. É importante considerar como esses custos serão gerenciados. Portanto, existe também o custo do time de pessoas de TI, especialmente se ele precisar atuar em horários fora do expediente normal durante a janela de migração.
Testes e validações
As ferramentas de migração, o time de pessoas de TI e o time de testes, que vai ser responsável por testar a migração, também precisam ser considerados. Esse time de testes se encaixa nos mesmos custos de final de semana, horas extras e banco de horas. É importante ter isso em mente, pois esses custos adicionais podem impactar o orçamento geral da migração.
Tomada de decisão
Agora, vamos falar sobre a tomada de decisão.
Priorização dos serviços
Quais serviços serão priorizados para essa migração? Quais serão migrados primeiro e quais ficarão por último? Essa decisão deve ser tomada com muito cuidado, pois, dependendo da escolha, a janela de migração será diferente, com tempos distintos e níveis de criticidade variados.
Investimento em feramentas
Quais ferramentas precisaremos utilizar após a migração? Estávamos considerando os sistemas legados. Como esses sistemas vão se comportar na nuvem? Quais ferramentas adicionais serão necessárias para garantir o funcionamento adequado?
Será preciso pagar por ferramentas de log, como as oferecidas pela AWS ou pela Azure? Como vamos monitorar tudo isso? Essas questões precisam ser levadas em conta de forma cuidadosa.
Gestão de riscos
Sempre deve haver uma gestão de riscos bem estruturada, pois não há garantia de que tudo estará 100% seguro. Algo imprevisível pode acontecer a qualquer momento. Não é possível prever todas as situações, por isso é essencial que a gestão de riscos esteja bem definida e preparada para qualquer eventualidade.
Conclusão
Como aprendemos nesta aula, passamos por todos os processos necessários para o planejamento de uma migração de sistemas legados para a nuvem. Tivemos uma visão abrangente, abordando diversos tópicos cruciais que precisam ser considerados nesse tipo de projeto.
Sobre o curso Multicloud: da migração à otimização de custos
O curso Multicloud: da migração à otimização de custos possui 96 minutos de vídeos, em um total de 31 atividades. Gostou? Conheça nossos outros cursos de Google Cloud Platform em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
- Arquitetura multicloud e migração de serviços
- Gestão de acessos e conectividade segura
- Escalabilidade e alta disponibilidade
- Resiliência e recuperação
- Monitoramento de custos e conformidade