Snow Software has been acquired by Flexera. Learn More.

Categorised as Product

Containers: With Emerging Technology Comes New Software Asset Management Challenges

By Mikael Ahlgren Andy Williford

Published on Jul 19, 2023

What are containers?

To put it simply, containers are packages of applications which run in isolated environments. They are not dependent on an underlying operating system the same way that virtual machines (VMs) are, as they are directly working with the host operating system. This means that they are more lightweight than VMs in terms of storage requirement and normally require fewer IT resources to deploy and manage. One could see why this market is growing at a rapid pace.

While the technology has existed for quite some time, widespread adoption and accelerated growth started a few years ago.

According to a publication by Gartner® in 2022, the container management market will grow at a rate succeeding 25% year over year (YOY) with an estimated market value of $1.4 billion by 2025. One recent analysis by Data Bridge Market Research published in Bloomberg even suggests over 30% YOY growth and a market value of 40+ billion USD by 2030.

New software asset management challenges

What does this mean to you working within the ITAM/SAM area? As with any adoption of emerging technology, disruption follows. The key challenges from an ITAM/SAM perspective include:

Lack of visibility
Containers are isolated environments, rendering traditional technologies extremely inefficient for gathering any information about the software and applications residing within them or how they are being utilized. Existing methods software asset managers utilize to understand software use, largely agents deployed on physical or virtual servers, are not transferrable to container environments due to the ephemeral nature of containers and the potential massive scale of these environments.

Lack of control
The technology is great from a flexibility point of view, but can potentially become a nightmare to manage as changes can occur rapidly with spinning containers up and down as required.

Lack of cost management
The phrase “you cannot manage what you can’t see” is highly relevant in this context. Without sufficient visibility, it becomes impossible to comprehend or quantify the costs incurred, leading to minimal to no cost control when it comes to licensing implications of running software in containers.

Potential risk of software compliance
The licensing rules of running software in containers differs from vendor to vendor. In certain cases, the licensing rules are container-specific. As both control and visibility are key challenges within this area, it makes the task of managing compliance seemingly impossible. This can be especially difficult if there is no clear governance structure within the organization where the SAM/ITAM team is involved in container management.

Even with complex challenges, this is a necessary undertaking

Even though it’s hard, you’ll need to get your arms around how to calculate your effective license position for commercial applications, regardless of the workload implementation (VM, server, container, etc.). When you get audited, the vendor won’t care that it is hard for you to gather the details to prove your compliance position. Key questions to consider in determining your position include:

  1. What licensable commercial applications, components or libraries are running in the environment? (OS, application products)
  2. What are the applications’ license rules and licenses required based on container limits, nodes, etc.?
  3. What is the potential cost?
  4. How do I know what my IT/engineering team has set up, taken down, and how long it was run in the environment?
  5. How do I measure the usage of software in the container environment?
  6. What are the hardware components (underlying infrastructure) to align to the license requirements? 
  7. Do I have enough licenses to be compliant?

What licensable commercial applications are running in our containerized environment?

The first step in your research is to understand what your organization is doing with containers, what commercial applications are used and what orchestration platforms are leveraged (some orchestrators include OS licenses – see OpenShift).

Start your research by connecting with your IT Infrastructure Operations teams, Software Engineering teams, or your SRE team. Ask how they track licenses. In speaking to some teams, some tag the images to track the licenses and then pull point-in-time data to determine how many images have those license tags.

Another option is to look into your public cloud billing data to determine if you are being charged for container usage. If you have a cloud cost management tool this will be easy to pull.

What are the licensing rules for running the commercial application in containers?

Licensing commercial applications in containers varies by vendor. We’ve provided a summary of licensing rules with resources for key vendors. Also included are resources to bookmark, as licensing rules can change.

Microsoft container licensing

Licensing Windows Server for containers

Physical Core Licensing Windows Server Standard (with Hyper-V isolation)

Physical Core Licensing Windows Server Standard (without Hyper-V isolation)

Virtual Core Licensing

Windows Server Datacenter

Licensing SQL Server for containers

Active SA or subscription is required to license container environments.

Individual Containers

Physical Core Licensing (SQL Enterprise Edition)

Virtual Core Licensing (SQL Enterprise/Standard Edition)

Resources:

Oracle container licensing

Whenever a container image is pulled to a host or K8 node with Oracle software, the product must be licensed using the Processors metric for the number of processors of the physical host.  If the host is virtual, then use of the Oracle Partitioning Policy dictates the number of processor licenses. This means that all the same hard- and soft partitioning rules that apply on traditional VM’s also apply to containerized environments.

Resources

IBM container licensing

IBM has provided a tool, IBM Container License Service (CLS), that measures the vCPU capacity at least every 30 minutes and the maximum value will be taken as your available vCPU. If organizations opt to not use this service, they will be charged for all cores in the cluster.

Unfortunately, IBM does not accept reports from third-party tools to track license compliance in containers.

IBM charges based on the sum of vCPU limits of the containers in a pod, capping at the physical capacity the worker node, either virtual cores or physical cores reported by the Kubernetes API. vCPU capacity will be aggregated at the cluster level, rounding up for fractional values.

Resources

Red Hat container licensing

Red Hat Enterprise Linux subscriptions seem the most straightforward and containers are counted similar to a VM (the instance of where the software is executed and whether it is the VM or container). 

Resources

How do I monitor commercial application use in containers and determine the licenses required to stay compliant?

As mentioned previously, container management is an evolving market and how to track license compliance in containers is not an easy problem to solve because of the large scale and ephemeral nature of containers. We can handle complex environments and simplify the process for you and your team. Reach out to us to get started.

Explore more on