The Path to the Cloud
- Prepare your integration environment. If you don't have one, it's time for you to have one. If you do have, it's time to make sure that it's 100% compatible with your production environment. We'll use this environment in order to stimulate the migration.
- Arrange your DNS records. Migrating to another location will probably require modifying your DNS records to reflect the new location. Some hosting providers do not allow naming for external locations (for example GoGrid is an example for such a provider). So you should verify that you know how to change your DNS records, or migrate the records to another register.
- Implement a DRP environment. You should have one first in
your current provider environment in order to eliminate issues such as
access lists and network latency. Why is it so important?
- Hosting migration is risky. You would like to have easy to roll back in case of non successful migration
- Data Migration take a lot of time. If your databases (or NoSQL) are large, it will take a long time to migrate them between locations (even using a 100Mb channel, it will take a 3 hours downtime to migrate a 100GB database). The most efficient way to shorten this time will be by using Log shipping between the databases, or implement a replication between 2 NoSQL sites. When you'll choose to perform the migration to the new site, all you'll need to do is stopping the primary instance and turn the passive instance to primary one. Since the data is being replicated between sites all the time, the data migration time slot will be minimized to at most few minutes.
- Migrate your DRP environment to the new cloud provider. Start with the integration environment in order to verify there are no network issues in implementing it.
- Verify the new provider stability. Now that you have servers in the new hosting provider, it's time to verify it stability, its network performance and any other issues that may arise and you were not expected to.
- Implement a Reverse Proxy Solution. Some of your client will be ready for the migration. They may have old stale DNS records or they might use your IP address for some kind of reason. Using reverse proxy can help your routing traffic from your old location to the new one, minimizing lost traffic and downtime.
- Perform migration test in the integration environment. You should turn the passive site into active one, and check that user can continue work after the downtime. You should document the process, and if times are not good enough, you should exercise the process. After you are satisfied with results, it's time for prime time.
- Migrate your production DRP site the new hosting provider. Perform the process in a similar manner to the integration DRP migration.
- Prepare for The big day. Transform your DRP (or the new hosting environment) into a production one.
- Verify. Wait a few days and verify the system was stabilized,
if so make few steps before closing your old hosting facilities and cut
- Implement a new DRP site both for the integration and the production environments.
- Verify that the routed traffic from the old site is neglected.
- The big day. it's time to shut down your old server, close the site and say bye-bye to your old provider.
Just Scale It
After doing so much work, it's time to decide what cloud items do you want to you. It may depend on the cloud provider offering, and your decision how and if you want to avoid vendor lock in:
- CDN: if you have major static files traffic, or if you are able to turn some of the traffic into static one (think of Linkedin profiles for example), you could store it in CDN facilities that offer can reduce your web servers traffic and better prepare your for peaks. It also can help you
- Queues: Avoid taking care of queues availability and let this internet giants take care of it.
- NoSQL stores: you could implement open source solutions such as Cassandra or chose the provider key value store.
- Rational Databases: Some cloud providers offer these days a database as a Service that let you get rid of these log shipping, clustering and care of daily backups. If you are interested, drop me a note and I refer you to some interesting companies.
- Load Balancing: You could choose using software based load balancers such as HAProxy, or choosing the cloud solution.
- Monitoring: Some cloud provider offer you a system monitoring, saving you major effort to monitor your servers.
- Separate back office services from web interfaces, creating pools of small machines that each can take care of their tasks.
- Parallelize your back end services, making sure that no single service turns into a future bottleneck.
- In case of push systems and communication between parties, create a directory system that can route events between different servers.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)