Recently, Ecommerce Developer moved to cloud hosting.
We thought our experience could help you plan and execute your own migration. What follows is a question and answer interview with Scott Meade, our principal Ruby on Rails developer who moved our custom application to the Amazon cloud. Meade is the owner of Synap Software, a Colorado-based Rails development firm. Brian Getting, our previous Rails developer, built the app. Getting is now a freelance Rails developer himself, running Terra Firma Design & Consulting, an Oregon-based firm.
Ecommerce Developer: We operate on a custom Ruby on Rails application. It just migrated from a staging slice and production slice at Engine Yard (EY), a Rails host, to a cloud environment at Amazon. Why make the change?
Meade: "As you mentioned, Ecommerce Developer runs on a custom Rails app. While the classic slices at EY met our needs, it really was overkill considering the cloud offerings out there. For example, we had the staging environment up and running 24x7, even though it was only used as part of demonstrating and deploying new features. Now, I boot the staging environment only when needed and then simply terminate it upon successful production deployment of new features. Amazon's EC2, and similar cloud offerings, make cloud computing more affordable and accessible. Plus, EY forced us to migrate as it was exiting the business of owning its own hardware."
ECD: Why Amazon? Why not another cloud host?
Meade: "EY is, essentially, a reseller of Amazon's cloud services. It made sense to retain the EY relationship while making the move to cloud hosting. EY's cloud offering runs on either Amazon or Terremark. We chose Amazon because it fit us better and it was less expensive."
ECD: Please describe the process to us. What were the steps involved?
Meade: "The final cutover looked something like this.
- Put up a maintenance page on the current environment.
- Stop the application.
- Dump and compress the database.
- Copy database dump to the cloud database instance.
- Load database.
- Update site records for new subdomain scheme.
- Copy over thumbnails, images, podcasts and other uploads.
- Copy over other assets such as PDF files.
- Test the new setup on EY cloud—this is the final step before sending users over to the new setup.
- Change domain names in EY application environments.
- Switch DNS to point to cloud IP address.
- Change sessiondomain in production.rb_.
- Add redirects.
- Restart web server.
- Test the app in EY cloud environment.
"This general plan was the result of test migrations onto a staging environment at Amazon. I set up the production environment prior to cutover so that the actual cutover event was mostly a matter of copying the newest database and other assets, changing the DNS entries, and changing the domain names of the EY application. There were also email and SSL steps involved."
ECD: What were the biggest challenges?
Meade: "One big challenge was accommodating the 'single IP address' and 'single SSL certificate' limitations of the new Amazon environment. Previously, Ecommerce Developer maintained a separate domain, EcommerceDeveloper.com. A limitation of Amazon's cloud hosting is that each hosting instance can accommodate just one domain. So, we switched EcommerceDeveloper.com to Developer.practicalecommerce.com. If we had not needed the subdomain change, the migration would have been more of a straight cutover.
"Another part of the learning curve was understanding and managing the relationships between environments, instances, and applications. EY's AppCloud Dashboard makes it relatively easy to manage each of these components and EY's AppCloud User Guide walks new developers through everything they need to know. I advise anyone moving to cloud to take the time and read through the documentation. A good up-front understanding will go a long way toward making for a smooth implementation.
"Finally, though certainly not insurmountable, there are tasks to consider in support of the loss of some 'freebies' that came with classic EY hosting. For example, because of Amazon limitations, AppCloud does not provide email services. We had been sending transactional emails, such as new account activation, from the previous application server. The move to AppCloud forced us to move to a dedicated SMTP provider, SendGrid, which is a good idea at any rate."
ECD: Can you elaborate on the need for combining domain names?
Meade: "The Ecommerce Developer platform runs both Ecommerce Developer and Practical Ecommerce. It is one Rails application serving two sites. Content is filtered and layouts are formatted based on the site the reader is currently navigating, searching, or otherwise viewing. Using one application for both sites makes for ease of maintenance, ensures that functionality is consistent between sites and provides automatic implementation of a single and shared user database. When you sign up as a user on Ecommerce Developer, you also become a user on Practical Ecommerce and can seamlessly flip between sites as, in reality, it is one Rails app.
"That said, EY's implementation allows just one SSL certificate applied per environment (this is based on Amazon's limit of one IP address per environment). Yet prior to the migration, we had two IP addresses to support two SSL certificates, one for EcommerceDeveloper.com and one for PracticalEcommerce.com. Moving to one domain name allowed us to continue to serve both 'sites' from one environment and keep portions of each site behind a single SSL."
ECD: What was involved there?
Meade: "There were some application changes, SSL changes, and environment changes required. When we added the concept of 'sites' to the application, it was done in a flexible manner such that sites are table driven behind the scenes. A site had a domain name, app title, and app root url. All content belongs to a site. Upon request, the app determines which is the 'current' site based on the host in the request (e.g. @site = Site.findby domainname()). The controller actions then scope all 'finds' and other activity to that site (e.g. @blogs = @site.blogs).
"To support the idea of subdomains, this implementation changed. I added subdomain details to sites such that requests with the 'www' subdomain set the 'current' site to Practical Ecommerce and requests with developer subdomain set the 'current' site to Ecommerce Developer.
"For SSL, we purchased and installed a new multi-domain certificate from Comodo. I had originally considered a wildcard certificate as a solution, but because the subdomains are known, we were able to use a multi-domain certificate, which is less expensive than a wildcard certificate.
"Other configuration changes included updates to the DNS records to point not only to the new environments but also to support subdomains."
ECD: You've been on Amazon cloud hosting for a few weeks now. What do you think, so far?
Meade: "I have been pleased. There were some initial performance glitches that I believe we have largely overcome."
