VM to Docker Migration
For the vast majority of organisations, the IT team have spent the last 10 years building and deploying applications into virtual servers. Compared to physical servers, virtualisation was a winner, and it provided a multitude of benefits; from a reduction in CapEx through consolidation, simplification of operations, enablement of streamlined DR, and simplified data protection.
Whilst the benefits were plain to see, over time the effective cost of the underlying virtualisation software has continued to rise. In part, this rise is due to software vendor "bundling" (forcing you to buy products you don’t need), but also due to the increased percentage of the hypervisor license cost in comparison to the cost of server hardware. Five years ago, a host server used to cost $100k and the Hypervisor $10k - 10% of the combined cost; now a host server is more like $30k, and the hypervisor license bundle $15k - 50% of the combined cost.
When weighing up the cost that the Hypervisor license contributes to virtualisation environments, many organisations are looking at cheaper (open source) alternatives, such as KVM or its derivatives. These might offer a better CapEx cost profile, but they also come with an increase in complexity and corresponding support implications through a smaller pool of available certified professionals.
Rather than simply replacing one "legacy" technology with another, Emerging Technology Partners would like to help customers understand the opportunity that Docker Containers provide; and using this as a "low cost" way to either reduce the hypervisor footprint, or be a complete replacement for the hypervisor.
Switching to a Docker Container based environment can reduce the server footprint by 45%, reduce storage consumption by 30%, and remove a large license burden through relinquishing (or shrinking) the hypervisor (and hypervisor management) layer. With Docker supporting both Windows and Linux containers, it is now feasible to migrate a vast proportion of legacy VMs into containers.
In addition to the hardware efficiencies that Docker containers can introduce, there are substantially enhanced capabilities in HA/DR, scaling, automated patching, and simplification of environment builds and testing.
Docker’s built-in cluster and network overlay technology, allows a single cluster to span any number of DC locations, or even into/across cloud providers. A container can be started in one DC, seamlessly restarted in another DC, or multiple instances of a container can be spun up across all DC locations. With overlay networking, containers are able to communicate with each other across a private network, regardless of the location of their supporting hosts. In addition, the built in TCP/IP load balancing provides seamless IP redirection to any container or container set (service), regardless of its physical location. All that is needed for containers to exist anywhere, is consistent access to persistent container data (NFS or S3). As long as a container host can access the supporting persistent storage, a container can be started on it. Due to the fact that Docker uses network file systems, there are no complex fibre channel or iSCSI metro cluster solutions needed.
Many people believe that Containers are only of use for new “stateless” applications; whilst it is true that new applications gain substantial benefit being architected in a micro-service manner, many of the same benefits are available to legacy “stateful” applications when they are refactored (migrated) into a set of containers. MySQL, SQL, or Oracle running in a VM can easily be ported (and still be fully supported) to MySQL, SQL, or Oracle running in a container. Web servers (web services) are some of the easiest to migrate; along with back-office infrastructure servers (domain controllers, DNS, DHCP, File servers). It is also quite common to find that many legacy applications have already been ported to Containers by the application vendor or their supporting community.
Due to the nature of containers, and that a container is considered “immutable”, DR can be obtained simply by recreating the container from its supporting image on new infrastructure, and container persistent storage can be replicated from the NFS/S3 server. The images that containers are based from can be stored either in private registries deployed across environments, or stored centrally on Docker Hub (or GitHub). This combined capability turns DR recovery into a couple of simple Docker commands (and in only a few seconds). Additionally, because all that is needed to recover a container is its persistent volume and source image, data protection can be achieved simply; by ensuring that the source image is retained, and any persistent volumes retained (through NFS backups), then the entire environment can be recreated in minutes.
The DR/Data protection capabilities also provide another key function, and that is for development and testing. An exact replica of production can be obtained and distributed in seconds (either with production data or without); and with the network isolation inherent in Docker, duplicated environments are unaware of their source systems.
In summary, if you have a large Virtual Server estate, and are thinking that there must be a more cost-effective way to deliver your application services, or if your IaaS invoice is spiralling out of control, then maybe it’s time to look at Docker, and how the team at Emerging Technology Partners can help.