MSPs frustrated by the cost and complexity of supporting VMs should look to containers.

September 3, 2019

4 Min Read
Medieval battle
A company is only as successful as its workforce is skilled. Today, those essential skills increasingly require a deep understanding of technology such as cybersecurity, artificial intelligence and predictive data analytics. It’s hard enough to find such talent, and it’s exponentially more difficult to make sure these workers are the right fit for the business and the company culture — and that their salaries stay within the company budget. Not an easy task. The difficulty is compounded by the fact that our workforce is aging out. Not only do CIOs need to staff for new technological skills, they also have to hustle to fill the holes left by longtime employees making their exits. Sometimes, the most efficient and effective way to fill those gaps isn’t with new employees. “We believe that the war for talent is a trend that is impacting all our clients and businesses around the country,” says Eric Rieger, president of WEBIT Services. “We have 10,000 baby boomers heading into retirement on average on a daily basis, and that trend is expected to continue for the next three to five years.  The impact for this on CIOs is that they need to leverage technology to be as efficient as possible since the talent pool will continue to shrink.”Shutterstock

By Rania Mohamed


Rania Mohamed

By Rania Mohamed, Solutions Architect, SUSE Global Services

Virtual machines have been instrumental in advances in cloud development and modern application and infrastructure design. But let’s face it: VMs have problems that are becoming more evident as technology stacks mature.

The three top problem areas:

  • Failover. VMs aren’t able to deliver high service-level agreements for failover. For every failing VM, a complete virtualized machine must be built — a technician must install the operating system, configure the network, install the application and configure the VM. While we do have some solutions today that can provide automation, this gap isn’t fully closed, especially if you must deliver a 99.99% SLA for an application.

  • Complexity. A VM is still a machine — it has a rich operating system, so it can be complex to install drivers, configure security and install and deploy applications. Complexity always matters to MSPs. It affects cost, maintenance, upgrades and the services you can deliver.

  • Cost of horizontal scaling and limitations of vertical scaling. VMs are pretty costly to scale horizontally and have limited ability to scale vertically. A question you might ask at this point: “Why do we need scaling? Let’s just plan out full resources ahead of time.” While it’s true that you could work with a customer to forecast all possible resource demands, it will cost you and them a lot of coin – a lot of coin – with no benefit and no revenue. For example, think about LinkedIn, or any other social platform. To prepare for the worst-case (or best, depending on your point of view) scenario so that the service is never down and always serving clients, it would need to provision resources for every current and potential subscriber to get access at the same exact time. That’s a lot of money, especially if you have variable load in the equation.

Shouldn’t a VM solve those problems? The short answer to that question is, unfortunately, no. VMs are built on the concept of handling monolithic, not modular, applications. With a VM, if there’s a need to scale horizontally, you’d need to add a completely new VM to the environment, with a full setup of the OS and application, even if the load demand is one single service or a couple of modules. As outlined previously, scaling horizontally using VMs isn’t cost efficient. Remember, there’s always a vertical scaling limit, which will vary based on the underlying infrastructure and the operating system and runtime.

The other problem for MSPs vis-à-vis VMs is time. Time matters to partners and applying a patch or upgrade, or performing a restart or rebuild, of a VM takes a technician away from other, higher-value tasks.

A Container Fix to these Problems?

I argue that yes, containers do fix these other problems. A container is essentially a lightweight, standalone application that holds all its dependencies and can run by itself. Let’s check out how that resolves the issues mentioned earlier:

  • A container has a very small footprint. The main aim of containerization is to break a solution down into small chunks, called a microservices architecture (MSA). With a container, a failed service can be rebuilt/built in nanoseconds and fully running in seconds. If the image used by the container is properly designed, it can even take a smaller amount of time. Containers use a lightweight operating system with a very small footprint.

  • Complexity of the solution. A basic architectural principle of containerization is simplicity. By running only what is needed by the application or MSA the container represents, there is no need to run a complete operating system and no need to know or care about the underlying host, making the container portable. A container is everything the app or MSA needs and nothing that it doesn’t.

  • Cost of horizontal scaling and limitation of the vertical scaling. One of the biggest benefits of containerization is scalability, as containers are built to run granular and standalone applications. If there is a need to scale due to load, more containers can simply be added – delivering the same horizontal scaling as a VM in a cost-efficient manner. Vertical scaling is no longer necessary with containerization, either.

Do Containers Replace VMs Completely?

Not entirely. To answer that question, let’s …

… check out when containers should be used:

  • If the load is a variable.

  • If frequent changes are required.

  • If the delivered solution is built as a service (SaaS or PaaS).

  • If the solution is multicloud or targeting multicloud.

If your customer’s needs don’t match the above, maybe a container isn’t right. But in the digital era, containerization is often a great option. MSPs should have recommendations prepared.

Rania Mohamed is a solution architect at SUSE Global Services with extensive experience in the field of software engineering involving software architecture, business analysis, technical design, implementation and testing. She has experience in dealing with a variety of professional software packages, programming languages and development/design tools. Follow her on LinkedIn or @SUSE.

Read more about:

Free Newsletters for the Channel
Register for Your Free Newsletter Now

You May Also Like