Cloud markets mature in Indonesia, the ranges of relevant enterprise options expand. Depending on your requirements.
These are the main hypervisors of choice
KVM: Note that KVM is an open source project, meaning that there is no licensing involved.
KVM runs on most Linux distributions today and is perceived as the default hypervisor to be used in all virtualization and cloud products offered by most Linux vendors. The open source hypervisor is also the default hypervisor used for most clouds today, probably making it one of the most widely used hypervisors in the world.
Hyper-V: Hyper-V is a Microsoft product and does not come free.
Hyper-V and Microsoft have always feuded with VMware. Over the past few years, they have managed to chisel away at VMware’s market share in the enterprise by providing a product that does most of what vSphere can do and at a more attractive price. It would be a natural choice if your workloads are Microsoft based, even though Microsoft is looking to support any and all Linux flavours in the future.
ESXi: The feature-rich hypervisor that many enterprises use is ESXi (vSphere). Of course, this is not a free product — VMware has built their whole company on their hypervisor and for many years this has been a great strategy.
It supports any operating system, be it Linux or Windows, with almost any kind of esoteric flavor that you could imagine covered by ESXi. But this is first and foremost an enterprise solution – one that might not be cost effective for everyone – especially if you are just starting out.
One of the biggest advantages offered when running a cloud platform on an Enterprise solution is the added benefits that come with this solution. Two examples (and for transparency, this is also true for Microsoft solutions) are Host restart and instance scheduling. In addition, VMware has built-in HA; in case a host fails, all instances are restarted on another host in the cluster – and your cloud solution does not need to manage or worry about these pieces.
Another example is DRS (Distributed Resource Scheduler), which is responsible for moving instances around between hypervisor nodes in the cluster. Again, this is something that is taken care of in the Hypervisor layer. As opposed to other cloud providers, this happens on a regular basis and not only upon instantiation.
Docker and a final note
It would be remiss to not mention the new kid (or container) on the block – Docker. Docker can run inside an instance on any of the hypervisors above. It is actually another abstraction layer on top of the hypervisor, which allows you to treat the hypervisor and in turn the cloud where you are running it as a commodity. Docker enables you to move between them in a much easier way than previously possible.
Even though your choice of cloud provider will be based on a number of different criteria, such as maturity, feature set or geographical location, there are cases where the underlying hypervisor capabilities will also be a contributing factor in your decision. Understanding the different features that each hypervisor can provide, its history and its share in the market will help you to make the best decision on which cloud to run your workloads.