Web development blog by Philipp Rieber
Finally, after preparing our application during the last few months bit by bit, it was time for the last and most important step: move the application code to an auto-scaling multi-server environment in the cloud and do a smooth DNS switch for the productive application. First we thought doing this with EC2 directly, but after some investigations we found solutions like Scalr, OpsWorks (the former Scalarium) or Elastic Beanstalk doing the heavy work for us. We decided in favor for Elastic Beanstalk - let’s see why and how.
In this part of my series we’ll get closer to the fundamentals of our application. In the last article we’ve outsourced our mail server to the cloud. Now we want to do the same with our database server to get rid of all the tasks that come with hosting a database server like setup, configuration, maintenance, backups, security, replication or updates. Amazon provides a really straightforward solution: RDS
Sending emails from a Symfony2 application is no challenging task. Just configure the Swiftmailer library with a handful of simple parameters, create a message object, trigger the sending process and you are done. Things change slightly if you are responsible of the mail server at the same time. Setting up and maintaining mail server software may become a challenging task, especially if there are complaints about missing emails, security holes or spam issues. Moreover, sending from a cloud server is not very reliable because of its doubtful IP reputation. Amazon’s SES service provides relief.
Moving to the cloud mostly means moving to a scalable multi-server environement with a load balancer in front. The load balancer redirects a user to an available web server instance of the cluster. Imagine a form with an image file upload somewhere in your application allowing a user to publish an avatar on his profile page. Handling the uploaded file the old way would mean to store it on the current web server’s file system. But how could this file be accessed by other web servers of the cluster, e.g. to display the avatar in the user’s public profile to users that have been redirected to another instance of the cluster? Moreover, what happens if we want to scale down our multi-server environment – meaning that we may need to shut down a web server that stores uploaded images? One possible solution would be to setup an additional file server for this purpose, not being part of the scaling cluster. All webs servers could access uploaded files at the same central location. But there are several drawbacks with this setup: First, it means setting up and maintaining another server with a different configuration. Second, it means a single point of failure: if our single file server fails then the whole application is concerned – and for the sake of simplicity mirroring the file server is not an option… S3 to the rescue!
This is part 3 of my series of articles about our first application move to the Amazon Cloud. As we are not the owner of the productive domain of the application, all communication about DNS changes has always been quite tedious, time consuming and prone to errors in the past – especially when your contact person lives in another time zone. In preparation to the final application move to EC2, which involves some DNS changes to switch to the Amazon load balancer, we wanted to gain some flexibility. Enter Route 53.