Virtualisation & IaC
Last updated
Last updated
When discussing infrastructure as code, virtualisation is a fundamental concept. Virtualisation technologies, when used in conjunction with IaC, allow for some powerful and efficient infrastructure management. While some of these concepts have been touched on in the Intro to Containerisation room, this task will review virtualisation and its relationship with infrastructure as code.
When we talk about virtualisation levels, we’re essentially talking about what is being virtualised. Here, we will briefly review the difference between hypervisor-level virtualisation and container-level virtualisation to provide context for upcoming concepts. Hypervisor virtualisation (e.g. VMware) enables multiple virtual machines to run on a single physical server. Imagine a physical server in a data centre. Using a hypervisor, this server’s resources (CPU, storage, etc.) can be divided and dedicated to separate virtual machines within this server. These machines will virtualise everything from the operating system, which can be a different OS than installed on the host, meaning multiple OSs can be installed on a single server; however, deploying a virtual machine at this level can take some time. Containerisation (platform example: Docker) is virtualisation at an operating system level, meaning the same operating system kernel is used to run multiple containers. Virtualising at this level makes these containers incredibly lightweight, allowing for rapid deployment and scaling.
Let’s consider how virtualisation is used in IaC across six areas: Scalability, Resource Isolation, Testing / Snapshots / Rollbacks, Templates, Multi-tenancy, and Portability.
Scalability | IaC uses virtualisation to meet demands (higher or lower levels of demand). If there is a sudden increase in demand (scaling policies can be defined in your code to specify when this would be required) and you need more servers, virtual machines can be created to handle this increased load. |
Resource Isolation | Virtualisation enabled resource isolation between different VMs/containers. Using IaC, you can define what components get how much of the available resources. This means if one component starts getting hammered (consuming all of its allocated CPU, memory, bandwidth, etc.), it won’t affect the performance of the other components. |
Testing / Snapshots / Rollbacks | The virtualisation of OSs, software configurations and dependencies makes it easy to package them and, using infrastructure as code, deploy them in another identical environment for testing or development. The consistency this provides, combined with the ability to take snapshots of VMs/containers at specific points in time so rollbacks can be done if a deployment goes wrong, streamlines development and testing processes. |
Templates | When using virtualisation, you can create a template (or blueprint) for VMs/containers. IaC can use these templates to provision new instances. These templates cut manual provisioning and configuration time down while ensuring consistency across instances. |
Multi-tenancy | Virtualisation can support multi-tenancy, meaning multiple customers/tenants can be hosted on the same physical server whilst having their resources isolated. This removes the need for dedicated servers/single-tenant environments (although sometimes they are required), and using IaC means the resources for multiple tenants can be managed using the same underlying infrastructure. |
Portability | Virtualisation makes it easier to move infrastructure between cloud providers or data centres. Having this portability, as discussed, can streamline critical business processes like disaster recovery but also allows the flexibility for hybrid cloud organisations to recreate environments regardless of their CSP. |
Next, we will discuss some virtualisation technologies used in conjunction with IaC to unlock its power, focusing on Kubernetes. Kubernetes (also referred to as K8s) is a containerisation orchestration software, meaning once an application (and its dependencies) have been containerised, Kubernetes can be used to automate its deployment, scaling and management. Using Kubernetes requires a Kubernetes cluster, in other words, an infrastructure made up of a master node and one or many worker nodes (where the containerised applications run). Infrastructure as code tools can provision the underlying infrastructure needed for this Kubernetes cluster and automate the set-up of the required Kubernetes components. Infrastructure as code can also define scaling policies for a Kubernetes cluster, automating the scaling process and allowing pods/nodes to be added or decreased based on resource usage. The infrastructure provisioning/configuration and automation capability of IaC, combined with the ability to orchestrate lightweight rapid deployable containers, make for a very powerful set-up and is ubiquitous in the world of cloud computing.
Consider a practical example from the world of DevOps. Say a DevOps Engineer is planning to deploy a new web application from scratch, and their tech stack includes both Terraform and Kubernetes. They can combine these tools and use Terraform to automate the creation of a new Kubernetes cluster, and once this cluster has been deployed, any other resources that might be needed, like a Nginx web server or a load balancer. This is just a simple, stripped-back example of a task that would even be possible by just using Kubectl (or other CLI-based tools) to manage K8s clusters and resources; however, using an IaC technology like Terraform boasts many benefits when you start to consider DevOps at the scale of a larger company where these tools allow you to define Kubernetes deployments, services, config maps etc. as Terraform modules, which are repeatable across different projects/clients/environments. We've also discussed how Terraform is a declarative tool ensuring that the state of the Kubernetes cluster matches the desired state, making infrastructure management an easier task. Terraform is also aware of dependencies, meaning if 'resource x' is dependent on 'resource y' and 'resource y' fails to deploy, Terraform won't attempt the creation of 'resource x'. Another way in which Terraform can save time is by reducing the need for DevOps Engineers to sift through deployment errors, working out the point of failure. Again, both of these tools are powerful, but when used together, their true power and utility in the DevOps space are unlocked.
Kubernetes is just one example of how virtualisation technologies and IaC can work hand in hand and are nearly essential to each other (at least to get the most out of the respective tool). Some other examples include Vagrant (used by developers to spin up and manage VMs or containers for local development and testing; IaC can make this a consistent process) and OpenStack (an open source cloud computing platform where you can create your own cloud environments where IaC can also be used to automate the provisioning and management of cloud resources).
This is just an overview of virtualisation to emphasise its use within IaC, but if you want to learn more, we have plenty of rooms that go in-depth on this topic, like Virtualization and Containers and Intro to Containerisation. Check them out!