Containers: With Emerging Technology Comes New Software Asset Management Challenges
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:
- What licensable commercial applications, components or libraries are running in the environment? (OS, application products)
- What are the applications’ license rules and licenses required based on container limits, nodes, etc.?
- What is the potential cost?
- How do I know what my IT/engineering team has set up, taken down, and how long it was run in the environment?
- How do I measure the usage of software in the container environment?
- What are the hardware components (underlying infrastructure) to align to the license requirements?
- 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)
- When all cores of the physical server are licensed (minimum 8 cores per processor and 16 per server), you are allowed to run two OSEs or two Windows Server containers.
Physical Core Licensing Windows Server Standard (without Hyper-V isolation)
- When all cores of the physical server are licensed (minimum 8 cores per processor and 16 per server), you are allowed to deploy unlimited Windows Server Containers.
Virtual Core Licensing
- When licensing by virtual machine, customers may use one OSE or one Windows Server container with Hyper-V isolation, subject to a minimum of 8 core licenses per OSE and 16 per customer. Use of any number of Windows Server Containers without Hyper-V isolation are permitted within any properly licensed virtual machine. Licensing by virtual machine requires active Software Assurance or a subscription license.
Windows Server Datacenter
- Datacenter edition provides rights to use Windows Server in unlimited OSEs, and any number of Windows Server containers with or without Hyper-V isolation, when all cores on the server are licensed (subject to the same minimums as standard edition).
Licensing SQL Server for containers
Active SA or subscription is required to license container environments.
Individual Containers
- Using the Per Core model, customers must purchase a core license for each vcore (or virtual processor, virtual CPU, virtual thread) allocated to the container. There is a four-core license minimum per container.
- Using the server license model (standard edition) a server license for each VM or container is required, and a CAL for each user or device.
Physical Core Licensing (SQL Enterprise Edition)
- Customers who have licensed all physical cores (minimum 4 cores) on the server can run any number of VMs/containers equal to the number of core licenses assigned to the server. A server with 16 core licenses can run SQL server software in up to 16 containers.
Virtual Core Licensing (SQL Enterprise/Standard Edition)
- When licensing the VM cores (minimum 4 cores, including HT cores) where the SQL containers are running you may run unlimited SQL containers on that VM.
Resources:
- Containers vs. virtual machines | Microsoft Learn
- SQL Server 2022—Pricing | Microsoft (Review the Licensing Guide and Datasheet for details)
- Windows Server and SQL Server licensing in containers (samexpert.com)
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
- Running and licensing Oracle software in Containers and Kubernetes
- Understanding Oracle Docker Licensing Requirements (redresscompliance.com)
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
- Container licensing | IBM
- IBM container licensing – new rules – The ITAM Review (itassetmanagement.net)
- Red Hat OpenShift | IBM
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
- Red Hat OpenShift enterprise Kubernetes container platform
- Try Red Hat OpenShift
- Red Hat Enterprise Linux subscription guide
- Self-managed OpenShift sizing and subscription guide
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. Snow Software is actively working to solve this problem and is now able to recognize some commercial applications in Kubernetes environments with minimal configuration. To learn about future product enhancements, subscribe to our newsletter and see what’s new at Snow Software.