Image of openshift development console

Cloud VMs or Containers

Containers or Virtual Machines in your Cloud Design?

I would not be an engineer if I did not muse over what kind of infrastructure I wanted my coded applications to sit on. One of the biggest architectural decisions to be made in any digital product is the housing for your coded application. There are two main choices. You can have Virtual Machines that have their own operating system but are isolated on a physical server from other resources hosted on it or maybe a dedicated physical server for your VM at a higher price point. Also of note is containers, which are lightweight and isolated application wrappers on top of VMs that share underlying logical server resources (VM). Container technology has matured greatly over recent years and raced past VM technology with the help of Kubernetes and a host of cloud provider products. The big leap for digital businesses has been of course abstracted Kubernetes orchestration products like EKS by AWS, Openshift by IBM and AKS by Azure. These technologies offer nearly immutable abstractions of the classic kubeadm build and are incredibly efficient in container orchestration increasing application reliability, and of course availability. Whilst containers do have their drawbacks, the benefits are considerable for SaaS companies noting the following use case considerations:

  • Your application requires 24x7 operation or is a short burst application to run back-end jobs in excess of 15 or so minutes that may suit a pay-as-you-go managed option like AWS Fargate.
  • Your application is cloud native and coded for scaleable container interaction targeting specific backend services and containers for operations.
  • Your database is cloud-native or migratable onto cloud resources. Compatible relational databases would include MariaDB, Postgres, MySQL, SQLServer and Oracle. NoSQL solutions like MongoDB plus more are available but if you are using NoSQL, consider your throughput needs and the suitability of containers in meeting them. The main advantage of containers is speed and not throughput.
  • Availability is important and you want to automate certain tasks such as orchestration.

All these are good reasons to choose containers with Kubernetes adding an extra layer of orchestration automation for scaling containers on appropriately provisioned and monitored nodes that can in themselves be scaled in Auto Scaling Groups/Machine Sets. So, I guess you can see how containers make sense but let's not forget the beauty of virtual machines, which directly support containers and also have use cases of their own outside of containerisation. If your use case has the following elements, you may want to directly use VMs instead of containers:

  • You have legacy applications that have been running on servers for a number of years and don't have the time and/or access to developers to sort out the legacy code that is not modular or altered for use with cloud services.
  • Your database is not compatible with containers or requires too much work in the time frame allotted to reach a migratable state for advanced cloud service offerings like container products.
  • You have cost considerations and containers are just too dear. You do however want to avail of cloud services to provide higher resiliency then a single AZ deployment. Your needs are met with services such as Auto Scaling Groups on AWS to create a steady state group of max 1,  min 1, and desired 1. This will allow the instance to be relaunched in any of its host region AZs should it fail.
  • You are not deploying web applications and have massive throughput needs in your requirements such as a big data mesh network that requires special infrastructure support with high throughput, memory-optimized and if using OLAP streaming, high I/O capable VMs to handle huge loads. 

As you can see, VMs are not going to disappear from the cloud landscape in the foreseeable future. With the arrival of mature container technology, knowing what use case suits what technology in your stack can mean the difference between the success and failure of your digital product. Stay tuned for more on DevOps in this blog along with articles on other areas of interest in the Writing and Cloud Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

Related Articles

image of a project timeline for a Maolte Technical Solutions Limited article on major incidents and digital migration

Major Incidents and Digital Migrations

Image of Jenkins workflow

CICD and Jenkins

Image of a runbook template header on Confluence for technical writing purposes

Effective Technical Documentation