Chameleon Technologies has been working on a document to help customers thinking of moving to the cloud with a list of things to consider so that we make the conversations around costing more productive. What do you think?
So you've been tasked with migrating a set of servers and services to the cloud. This is usually where people run to experts who have done this more times than they can count. Don't worry, we're here to help. There are a few things that you will need to think about before moving to the cloud.
1. Uptime.
Is the uptime expectation going to change when you go to the cloud? Often this is a simple conversation, but it can get a bit complicated. Usually the expectation of the cloud is that it is already built fault tolerant, and it will never go down: this true as far as the operations teams for your cloud provider are able to do so, but every system has its fault. (AWS notably lost a datacenter for more than 24 hours because someone forgot to get fuel for the generator.) There is nothing quite like doing an Azure migration and then the same day that the migration happens all of Azure stops working: that is a recipe for egg on your face. A good way to push this conversation in a more meaningful direction is to ask how many nines the customer wants. A good general rule in budgeting is that every nine beyond the first doubles the cost of the project, so if 90% uptime was $50k/yr, 99% uptime would be $100k/yr, 99.9% uptime would be $200k/hr and so on. A good cloud architect can help mitigate these scaling issues.
2. Scaling.
Now that the uptime value has been decided, you can have the conversation about scaling. Are we moving VMs from a datacenter into the cloud? Are we building something new that scales dynamically? Are we moving from bare metal on-prem to VMs on the cloud? Individual VMs can scale up pretty quickly, but if you don't have the CPUs reserved you will run smack into a wall at the worst possible time. Groups of VMs can scale horizontally, but may have locally stored information that make load balancing (and horizontal scaling) impossible. Dynamically scaling applications aren't without their difficulties: here a few things to consider (each with consequence); geo-redundant, local-redundant, dynamic upscaling and downscaling. If you can get these nailed down, your life becomes easier, as costs can be estimated and managed.
3. Recovery Model.
The final point to think on is simple but headache inducing. What scale of recovery do you want to have? Are we talking server level redundancies? Colo level redundancies? What about regional? It sounds like a pain. These questions can be converted to one thought experiment. What is our worst case scenario? Do we worry about earthquakes and hurricanes? Or would we rather focus on something more localized? The simple expedient is that if we decide the largest scale of disaster we want to account for, we put the recovery model somewhere beyond the reach of that problem. Simple.
