Virtual Containers: Asset Management Best Practices and Licensing Considerations - Part II
In part I of this two-part article, our objective was to understand containers – what they are, how they came to be, and how they compare to other technologies. In part II, we will look at containers in the cloud and CaaS, asset management best practices, and licensing considerations. Read part I here.
Containers in the cloud and CaaS.
Containers are a great fit for the cloud. As covered in part I, containers are much less resource-intensive to run than VMs. This means that containers are less expensive to run in the cloud than VMs.
Financial savings are not the only benefits of running containers in the cloud. The cloud is touted for its scalability and elasticity, however, dynamically scaling traditional Infrastructure as a Service (IaaS) workloads (be it right-sizing the instances or deploying them based on need) is much easier said than done. Containers, on the other hand, were built with this functionality in mind and orchestration makes scaling and meeting demand simple.
Download a copy of the whitepaper!
Often, when talking about containers in the cloud we hear the term CaaS (Containers as a Service). CaaS could be regarded as a sub-category of IaaS, except we don’t need to manage the OS itself; we are just managing the containers and container runtime.
With IaaS, the cloud provider is providing the infrastructure and we just manage the OS and applications. With CaaS, the cloud provider is also managing the container platform, so we are just managing the containers themselves along with any orchestration.
Public cloud providers including Google, Amazon Web Services (AWS), IBM, and Rackspace all have some type of CaaS offering. They offer the ability to run the entire container platform including registry, orchestration, etc. on the cloud.
Once containers are in use, they must be managed and licensed properly. Unfortunately, the very features that make containers so technologically compelling also make them difficult to manage.
Trustworthy Data The first thing that should always be considered when managing IT assets is ‘Trustworthy Data’. You simply cannot manage what you are unaware of. So, before anything else, you must have a way to gather data from your existing physical and virtual infrastructure and ensure that the data is trustworthy. This means putting the proper tools in place as well as processes to check the accuracy and completeness of the data gathered.
So how do we get the reliable data needed to effectively manage containers?
Due to the nature of containers, traditional data collection methods won‘t work. Physical machines and VMs have an OS installed that supports SSH, WMI, or an agent that information can be gathered from. Containers don’t have this same level of access available so a tool would have to directly interface with the container platform (typically Docker) and any orchestrators (e.g. Kubernetes). In 2019, SAM tools don’t fully support containers. As such, discovery and tracking currently require efforts that are much more manual. Because of the current manual nature of tracking containers, it is likely you will need to take a tiered approach to understand high-risk applications that should be closely monitored versus low-risk applications which may only need infrequent or ad-hoc monitoring.
However, one positive benefit for ITAM is that containers can have audit trails in place. The container registry contains a master catalogue of the container images used in the environment and containers are typically tagged and grouped, which should help identify what is running in the container. Some registries, such as Dockerhub and Azure Container Registry (ACR) keep of log of each deployment of an image as well as who built it; such a log is an invaluable resource for an ITAM manager. The container manifest, which is different from the registry, will also reference any parent containers.
People & Processes During the annual Docker conference in 2017, the keynote speech included the following hypothetical situation:
Two engineers come back from vacation to discover that they need to quickly stand up an application that also requires an Oracle Database. Using containers, they quickly deploy the Oracle database by downloading the container image from the official Oracle Container Registry and turn what would normally be an onerous and multi-day endeavor into a process that only takes a few minutes.
While the scenario highlights the benefits of containers it also shows how an incredibly powerful benefit could quickly become a nightmare if the proper policies and procedures are not in place.
Containers lower the barrier to entry in deploying enterprise-grade software. One consequence of this is that it becomes much easier for admins and others, who may not be aware of the cost and licensing implications, to install costly commercial software. Proper policies and procedures can greatly mitigate such risks. It is therefore crucial that these policies and procedures not only exist, but that employees are educated and trained accordingly so that such a mistake does not happen.
Licensing can also be complicated by running applications in containers. In this section we will look at specific licensing considerations for Microsoft, Oracle, and IBM.
Microsoft Microsoft has two different kinds of containers: Windows Server containers and Hyper-V containers.
Windows Server containers provide application isolation through a process and namespace isolations technology. Like traditional Linux containers, Windows Server containers share their kernel (the most core instructions/functions of an Operating System) with the container host OS. However, because they share the kernel, these containers require the same kernel version and configuration. From a licensing standpoint, you can run unlimited Windows Server containers without additional licensing considerations.
To date, Hyper-V containers have been essentially optimized virtual machines. The kernel of Hyper-V containers is not shared with the host, meaning that the configurations and versions do not need to match. However, these containers will be much larger in size. Because the containers are redistributing the OS kernel, the container OS must be licensed. From a licensing standpoint, Microsoft treats these containers as if they were VMs. This means that licensing the container OS is straightforward for those who are already familiar with licensing Windows Servers on VMs: Once the physical hosts cores have been licensed, Windows Server Standard can cover up to two containers (and be stacked multiple times to cover additional containers) while Windows Server Datacenter can cover an unlimited number of containers running on that host.
Microsoft also has two Windows Server operating system editions that are commonly used in containers – Windows Server Core and Windows Server Nano Server. These editions are ideal for containers as the OS has a smaller file size. Windows Nano Server in particular is designed for scenarios that require “fewer patches, faster restarts, and tighter security”. Because Windows Server 2016 Nano Server receives updates using the ‘Semi-Annual Channel’, Software Assurance (SA) is required on both the server licenses as well as the CALs (Client Access Licenses).
Just like Windows Server operating systems, Microsoft treats containers like VMs when licensing applications. Here’s an example: when licensing SQL Server within containers, like VMs, you can license the subset of CPUs cores that are dedicated to that container rather than licensing all of the physical cores supporting the container platform. Additionally, if all of the host cores are licensed with SQL Server Enterprise w/ SA, an unlimited number of SQL Server containers can be run. Keep in mind, however, that unlike VMs, where we explicitly assign CPU, RAM, etc., containers will, by default, use all resources available unless specifically configured otherwise and you have to go out of your way to explicitly define how many resources a container can use.
Oracle Oracle has more of a hardline approach with its products and virtualization technologies. Oracle has a ‘partitioning policy’ with listed supported technologies, which means that when we are using a supported technology, then we only need to pay the licensing costs associated with the CPUs supporting those partitioned workloads. This is referred to as ‘hard partitioning’. Everything else falls into the definition of ‘soft partitioning’.
Containers, such as Docker, are considered ‘soft virtualization’ by Oracle. Should an Oracle product be deployed within a container, all physical infrastructure that sits underneath that container – including all servers within the cluster, farm, etc. – must be licensed. There is one exception to this: versions 9.x and up of Oracle 10 Solaris containers, also known as Solaris Zones, are recognized as a ‘hard partition’ technology if they are ‘capped zones’.
While it’s not possible to license the subset of CPUs supporting a workload with Docker, once the infrastructure is licensed, we can run an unlimited number of container instances on it without additional licensing considerations. And because containers are lighter weight than VMs, we can also typically run more of them.
IBM IBM has taken a very similar route as Microsoft in that it treats containers like it treats VMs. This is great for those already familiar with IBM’s licensing models, especially its PVU metric-based licensing which allows customers to take advantage of subcapacity licensing. However, there is some specific guidance from IBM on ensuring eligibility for PVU licensing:
“Docker is not a sub-capacity eligible virtualization, but it can be used in combination with a sub-capacity virtualization. … Apart from discovering IBM software that is installed in Docker containers, License Metric Tool also reports its license metric utilization. When the Docker is deployed on a physical host, license metric utilization is calculated on the level of the host. When it is deployed on a virtual machine, utilization is calculated on the level of the virtual machine.”
This means that if we deployed containers on a physical host, we would need to license the PVU equivalent for all the host’s cores, regardless of how many were accessible to the container. However, if we deployed the container runtime in a VM using virtualization that is eligible for sub-capacity licensing, then we would only need to license the cores assigned to the VM. This also requires ILMT or BigFIx clients on the host or VM. ILMT added Docker software scanning support in December 2017 and it is available from 9.2.5 onward.
Containers are only going to continue to grow in usage and popularity and that’s having a solid grasp on how they operate is required in order to effectively manage them. Containers, cloud-based services, and other serverless functions necessitate the need for a mature SAM and ITAM program, processes, and reporting. It also increases the need for tools and solutions that can provide real-time actionable information to optimize costs and mitigate security risks. If you have any questions regarding SAM and containers, reach out to us and we’ll be happy to help.