Traduzido do 日本語 • Ver original Olá. Aqui é Akiyama, um engenheiro Azure. Desta vez, vou escrever sobre a migração do meu sistema LAMP da AWS para o Azure.
Arquitetura Pré-Migração
O sistema é uma configuração ortodoxa de LAMP.
A seguir é uma configuração comum.
- DNS(Route53)
- Balanceador de Carga (ELB)
- Servidor web (EC2)
- Servidor em lote (EC2)
- Cache (ElastiCache)
- Banco de Dados (RDS)
Problemas
Os problemas que queríamos resolver eram os seguintes.
- Seu servidor web é overspec
- A implantação em produção é feita copiando o EC2 do ambiente de desenvolvimento por AMI. Além disso, existe apenas um ambiente de desenvolvimento e o código-fonte não é versionado
- Terceirizou a produção, mas ninguém na empresa fez isso.
- Um serviço que os membros do Azure valorizam está rodando na AWS
Arquitetura Pós-Migração
Embora esse sistema seja operado internamente, o número de usuários não é tão grande e o impacto do tempo de inatividade do serviço é pequeno, então adotamos o WebApp no Linux e o Azure Database para MySQL , que atualmente estão em prévia. Isso resultou em uma configuração apenas PaaS que elimina o IaaS.
Atualização de 2017/09/12: WebApp no Linux foi GAdatado para Web Apps para Containers.
- DNS(AzureDNS)
- Servidor web (WebApp no Linux)
- Servidor em Batch (Aplicativo Lógico)
- Cache (Redis)
- Banco de Dados (AzureDatabase para MySQL)
- Insight de Aplicação
Houve processamento em lote que foi acionado por requisições web, mas ao mudar do cron EC2 para o Logic App, eliminamos o IaaS e reduzimos custos. Monitoramos o serviço com testes de disponibilidade do Application Insight e conectamos o Logic App para alertá-lo no Slack.
Se você ainda quiser usar o serviço de prévia, precisa estar preparado para algum tempo de inatividade.
O que aconteceu
Vamos olhar para trás e ver os problemas um por um.
Escalonando Servidores Web
Problemas
O servidor web é sobrecarregado.
Resultados
O WebApp no Linux pode ser escalado de forma flexível, como a versão para Windows. Agora é fácil reduzir para as especificações mínimas exigidas.
Não é que eu não pudesse fazer porque tive que reduzir a escala no EC2, mas isso facilitou.
Fluxo de Implantação
Problemas
A implantação em Produção é feita copiando o EC2 do ambiente de desenvolvimento pelo AMI.
Resultados
Antes, nem podíamos controlar versões do código-fonte, mas agora o ambiente de staging é atualizado com uma série de fluxos de implantação de um push para o GitHub. Se tudo parecer certo, troque e pronto.
Manutenção
Problemas
Foi produzido por terceirização, mas ninguém na empresa fez nada a respeito.
Resultados
Esse processo de migração me permitiu pelo menos trabalhar nele por conta própria. Escrever este artigo também me ajudou a documentar a configuração da infraestrutura e o fluxo de implantação. Se você é programador conosco, não terá problema.
Seleção de Nuvem Pública
Problemas
Um serviço que os membros do Azure cuidam está rodando na AWS.
Resultados
Trabalhamos com vários fornecedores de nuvem pública. Como esse sistema era gerenciado por membros do Azure, pudemos usá-lo como um lugar para testar as tecnologias mais recentes do Azure que estávamos validando durante a migração.
Conclusão
Não só o Azure, mas também os serviços de nuvem pública estão evoluindo muito rapidamente. Ao combinar serviços corretamente, você pode alcançar o mínimo de monitoramento e aplicar o ambiente de desenvolvimento ao campo. Se você deseja um ambiente que permita focar no desenvolvimento, sinta-se à vontade para nos contatar.
