Pitfalls to avoid when moving VM's to the cloud.

Because many schools already run virtualized server platforms such as MS Hyper-V or VMWare it might seem like a good idea to replicate the on-premise virtual machines (VM's) to an IaaS platform (Microsoft Azure, Amazon AWS, Google Cloud Platform) to gain some of the benefits of working with the cloud.   Move the servers and you can tick that cloud box!

However believing you can organise and manage your servers in the cloud in the same way you do on-site fails to take into account some fundamental difference between the two platforms.

An onsite virtualised server farm is based on a model of fixed capacity which is essentially free (i.e a large server/storage block paid for with an initial capital sum).

Creating a new server carries little or no additional cost which is why so many sites end up with end up with virtual server sprawl. You can't afford to work that way with IaaS, it's too expensive.

The capacity distribution of the servers is also skewed in the wrong direction.

Within a local VM farm, running large instances are normally avoided because they are harder to balance out over a cluster. There is a tendency to create small single task machines that are easier to schedule on a fixed number of cores. Again IaaS doesn't have that limitation.

Lastly, to get value out of an IaaS platform you must maximise CPU cycles of each instance which is completely the reverse of local processing where you try to minimise cycles. This is because with on-premise you have a fixed capacity and are forced to operate with a buffer to allow for bursting and failover. The average CPU utilization of a on-premise server over 24 hours is 5-10% which is hugely inefficient. IaaS should plan to run machines at 70% CPU capacity to be cost effective which is simply not feasible for most installations.

Because IaaS has elastic capacity and a pay-as-you use model you would be making a classic error to take the same pattern of server deployment and replicate to an IaaS platform.

It would work  - but the solution would be massively inefficient and costly.

No comments:

Post a Comment