• Alex Konusa
  • May 16, 2022
  • 23:10 pm

What are software containers, and why should we use them?

My name is Alex Konusa, and I’m in my first year at Coliance. Turns out, my colleagues could step backwards a lot quicker than I could when asking for volunteers to write a blog post! My background is in development, so supply chains and B2B are all new to me – but I think it’ll be a fun challenge to try and collect my thoughts on them in this summary.

Containers have been around for a while in the development world, but have, in recent years, been rapidly gaining popularity within the IT sector. Despite this, they’re still treated as “the new kid on the block” in the Supply Chain World that I now work in.

Containers were developed as a solution to simplify many tasks and needs. The idea behind them is to is to bring together tasks that a developer might need, in a lightweight “contained” bundle” that is fully functioning in itself.They are able to facilitate a lot of tasks, such as: moving software from one environment to another, isolating the application with more ease. One obvious advantage is that differences in Operating Systems and its related heavyweight infrastructure are no longer a problem. These speeds up development and means development can be easily tested and deployed to production. Another big benefit is the ability to load, balance, and scale the environments within seconds.

There are plenty of container deployment methods available. There are options available in Cloud, such as AWS, Google, Microsoft, as well as local environments like docker to help with development. Which one you use depends on suitability for your software and company needs. Using them is one thing but making sure they are all working and in the right place is the job of “Orchestration” software like Kubernetes and OpenShift, but this is beyond the scope of this document today.

How are Containers different to virtualisation?

From a high-level Containers and virtual machines (VMs) can be very easily confused with each other, but they are really very different.

Think of it like this; The key differentiator between containers and virtual machines is that virtual machines virtualise an entire machine down to the hardware layers and containers only virtualise software layers above the operating system level. So, containers are much smaller in size than virtual machines; In many cases this can save a lot of capacity, power, and money which in a world where we are trying to prove our sustainability credentials is a very important consideration.

Virtual machines have a much longer lifespan and are best used for tasks that require long periods of runtime. Containers, on the other hand, have lower longevity with their short start up time, testing and deployment, and are better suited to smaller, discreet tasks, like those mentioned above, and with the ability to potentially have many of them are great for load balancing during busy periods.

Here at Coliance, I have recently been learning the use of containers to install IBM B2Bi, to develop, test and troubleshoot. We used Docker as a learning tool. In theory, containerisation allows us to create instances of B2Bi within a few seconds, eliminating the need to set up new instances of B2Bi on our development Virtual Machines which can be time consuming. The advantages include being able to simply delete the container and create a new one from an already existing image if a critical error occurs. The downsides were that we had to put a lot more thought into networking issues. It was interesting to see all the errors that the team were getting in this area. We found exposing ports to the console ’interesting’ and struggled to get items like the Map test tool and Process Modeller to work because of these complexities, but it was a great experience. Many of these problems go away when moving to OpenShift of course but that is for another day.

Related Articles

Let's get started

Book a consultation

Contact Us

Coliance © 2023 All rights reserved