Having trouble easily moving software from one environment to another? Surely this ought to be an uncomplicated process, especially in the modern age of technology! However, let us consider an analytical model built in a design environment to detect fraudulent credit card transactions. This is now ready to be rolled out to a production environment to catch those deceptive fraudsters. A minor blip is that both environments are running different versions of the software on different operating systems – and the former is located on-premises whilst the latter is in the cloud. Perhaps not as straightforward as it first appeared.

Containers to the rescue

Enter our knight in shining armor – the container. Containers are a lightweight and flexible virtualisation technology, compared to traditional virtual machines, and more cost-effective. You can deploy a container in a matter of minutes, then easily scale and update it. And it is also portable.

All that goodness aside, you may wonder what a container is, exactly. And how can it help an organisation’s technology and cloud strategy?

In this article I will provide an introduction to containers (for something more technical, see SAS and Containers: The State of the Union 2019 by Paul Kent). However, if you have heard of terms like containers, Kubernetes (or K8S as the cool kids call it), Docker and Recipes and wonder if these are all ingredients you can cook and store in your portable lightweight container, then this is probably a good place to start.

SAS on bare metal

Before we answer the “what is a container” question, let us look at what we used before containers. Traditionally we installed SAS on-premises – also known as "bare metal" – with physical servers dedicated to a single individual or company. This entailed working on a single operating system (OS), requiring upgrades and patches.

Though perfectly workable, this kind of installation was high maintenance at best. If you consider doing a spot of gardening, this type of environment would be like using an entire plot of land in your garden to grow some flowers rather than a plant pot. The downside to this is if you wish to move the flowers around, it would be difficult. Not impossible but certainly messy!

Virtual machines

Along came virtual machines, where suddenly the one operating system constraint was removed. Instead, you had the freedom to have multiple operating systems, each running its own applications and corresponding bits, such as libraries via a clever tool called a hypervisor. Back to our gardening analogy, this would be like planting your flowers in closed pots (ones without the little holes at the bottom). They are completely sealed, and each one could grow different varieties of flowers with a different soil type.

Whilst this would provide the advantage of portability, there would be duplication of space and memory. This option requires each application, each closed pot, to have its own OS running, along with the virtual machine needing to have its own host OS. If you decided it needed to be moved to the other side of the garden for more sunshine, it is certainly much easier than digging it all up. But it would mean, perhaps, a lot of heavy lifting with all those separate operating systems in there.

Containers

Containers are similar in concept to virtual machines but even more portable and efficient to run. You can run more containerised applications than a virtual machine. This is because a container does not need its own OS but is able to communicate with the host OS.

Continuing with our gardening example, containers are like planting flowers in pots with drainage holes at the bottom. So instead of being completely sealed like a virtual machine (and needing its own guest OS as well as the host OS), the application can simply access the host OS via the "drainage holes." Moving the lighter containerised flowers from one part of the garden to another is now even more effortless than with virtual machines.

Container example

Consider a physical server with three virtual machines, each with its own distinct OS plus a hypervisor and the host OS. In contrast, a containerised application with Docker (though not the only software container platform, Docker is by far the most popular one) would only require a single OS, the host, hence the ability to fit more applications. This consequently provides a major benefit in terms of infrastructure cost savings for the IT department.

Containers provide flexibility by allowing functionality of applications to be split into separate pots. Furthermore, you can easily replicate the containerised "pots." Thus if one should fail, you can promptly make another available. For organisations that make use of different operating systems in various parts of the business, containers certainly provide a solution, as one built for Windows can be run on Linux. The cherry on the container is true portability. One built on one’s own hardware in one own’s data centre can just as easily run in the cloud. In the opening example, the need to operationalise the on-premises test fraud model so it can operate in the cloud running a different OS now appears pretty straightforward.

Kubernetes

A containerised approach of working gives you ease of deployment, speed and the other good stuff mentioned above. And it also allows you to scale as the needs of your business changes. Managing a few servers can be relatively easy, but as you grow, it can get troublesome to manage. You may wish to use an orchestration tool, such as Kubernetes (often abbreviated to K8S to denote the eight characters between the "K" and "s").

You can use K8S to manage your containers, creating more when you need them and shutting them down when you don't. It works in a similar way to conducting an orchestra, deciding who will start playing and when. For example, you might need seven trombone players, followed by two violinists. The benefits of a containerised approach for organisations include infrastructure cost savings, ease of movement and scalability, and speed of model deployment. Can your organisation really afford not to consider it?

The industry is moving towards a containerised approach of working for speed, ease of deployment and portability. This article provides a 101 in #containers, #docker and #kubernetes. Click To Tweet

SAS and containers

You can containerise both SAS^®9 and SAS^® Viya^® with Docker and Kubernetes. And you can access them either via the SAS browser-based interface, SAS Studio, or Jupyter Notebook. You can deploy Docker containers in two ways – with a set of instructions called a recipe, which extracts the right SAS software component for an image build, or via predefined Docker images. For more information, see SAS and Containers.

For more information on SAS in containers, look here.