Translated from 日本語 • View original Hello. This is Akiyama, an Azure engineer. In this article, I will write about migrating LAMP's system from AWS to Azure.
Pre-Migration Architecture
The system is an orthodox LAMP configuration.
The following is a common configuration.
- DNS(Route53)
- Load Balancer (ELB)
- Web server (EC2)
- Batch Server (EC2)
- Cache (ElastiCache)
- Database (RDS)
Problems
The problems we wanted to solve were as follows.
- Your web server is overspec
- Deployment to Production is done by copying the EC2 of the development environment by AMI. Also, there is only one development environment and the source code is not versioned
- Outsourced production, but no one in the company has done it.
- A service that Azure members care about is running on AWS
Post-Migration Architecture
This system is operated in-house, but due to the small number of users and the small impact in the event of a service downtime, WebApp on Linux and Azure Database for MySQL , which are currently in preview, It is adopted. This resulted in a PaaS-only configuration that eliminated IaaS.
2017/09/12 Update: WebApp on Linux has been GAdated to Web Apps for Containers.
- DNS(AzureDNS)
- Web server (WebApp on Linux)
- Batch Server (Logic App)
- Cache (Redis)
- Database (AzureDatabase for MySQL)
- Application Insight
There was batch processing that was fired by web requests, but by switching from EC2 cron to Logic App, we have eliminated IaaS and reduced costs. We monitor the service with an availability test in Application Insight, which is then webhooked to the Logic App and alerted in Slack.
If you still want to use the preview service, you have to be prepared for some downtime.
What Happened
Let's look back on the problems one by one.
Scaling Web Servers
Problems
The web server is overspeced.
Results
WebApp on Linux can scale as flexibly as Windows version. It is now possible to easily reduce the minimum necessary specifications.
It's not that I couldn't do it because I just had to scale down in EC2, but it made it easier to do.
Deployment Flow
Problems
Deployment to Production is done by copying the EC2 of the development environment by AMI.
Results
Previously, we couldn't even version the source code, but now a series of deployment flows from push to GitHub update the staging environment. If there are no problems, swap and you're done.
Maintenance
Problems
It was produced by outsourcing, but no one in the company has done anything about it.
Results
This migration process has allowed me to at least work on myself. Writing this article also helped me document the infrastructure configuration and deployment flow. If you are a programmer of our company, there will be no problem.
Public Cloud Selection
Problems
A service that Azure members take care of is running on AWS.
Results
We have relationships with multiple public cloud vendors. The system was managed by Azure members, so as the migration progressed, it was able to be used as a place to test the latest Azure technologies that we were validating.
Conclusion
The evolution of public cloud services, not just Azure, is very fast. The right combination of services allows for minimal monitoring and more application of the development environment to the field. If you would like an environment where you can focus on development, please feel free to contact us.
