When it comes to cloud migration strategy, “fork-lifting” an application into the cloud is often frowned upon. Fork-lifting means simply swapping a physical server for a virtual cloud server. It really is the most basic cloud migration strategy and it does completely ignore several key benefits of cloud computing, including elasticity, scalability and the resilience of a distributed architecture. Nonetheless, there are times when a simple fork-lifting operation makes sense. This is the story of one of those times.
The technology director of one of our long-time customers called for advice on how to best upgrade/expand his corporate email service. It was the perfect time to address some longstanding issues with his current deployment. Corporate email for this customer had been running quite happily on a single HP server co-located in our datacenter, however the operative word here is “single” (as in point of failure), and there was no plan in place to deal with the inevitable failure of that server.
We could have thrown a second “warm spare” server at the problem, or kept some spare parts hanging around, but having a customer spend money on hardware that sits idle 99.99% of the time “just in case” is a very 2003 solution to a 2014 problem. We suggested moving into the cloud, and our customer was happy to take our advice. In this case, we were dealing with a steady, highly predictable computing and network resource load. Scalability and elasticity were not really concerns, and the email application in question is not written for a distributed environment, so we were looking at a basic fork-lifting project from the outset.
Our goals were simple:
- Provide adequate computing and network resource required to run the corporate email application properly
- Build-in the ability to migrate the application around extended cloud outages
- Build-in the ability to quickly recovery from failure in the form of software or data corruption
We fired up a large-ish instance in an Amazon VPC, attached two solid state volumes as data drives and went to work. A few days and some testing later, we were successfully syncing email between the old physical server and the new cloud based server. With some advance DNS and MX host prep done, we scheduled the cutover to the cloud server for a Saturday evening. We had planned on up to 3 hours of email downtime during the cutover, but increased sync frequency cut that down to less than one hour. When we were done, 400+ mailboxes has been migrated to the cloud, software had been upgraded, more seats were available to support a new venture, and not a single end-user really even noticed the switch.
Cloud migration – by way of a fork lift – accomplished.
While our customer is still relying on a single (virtual) server to handle corporate email, that server is imaged automatically each night and mailboxes are being backed up to a mirror volume.
- Recovery, both at the server level or for a single user mailbox, are both easy tasks now
- There’s no longer any worry about a dead motherboard bringing the company to a two-day standstill
- The migration was relatively easy and therefore cost the customer less than the cost of a spare server
- The monthly recurring cost is comparable to co-locating the old hardware server
- We’ve taken over management of the server so its another nuts-and-bolts issue that we’ve taken off their plates
In the end, while there’s no cool auto-scaling and load balancing at play, it would be very hard to look at this particular cloud migration strategy as a bad idea from any angle.
[Image credit Flickr/me5otron (Creative Commons License)]