Containers are being used in companies – I can bet on it, and you should too.

How do you track them to make sure use of Containers doesn’t create license compliance risk?
How and where are containers deployed?

Let me start by describing how Containers can be deployed before talking about different ways to track the software running in them.

Did I mention there are different Container technologies?  Yes, there are, although we can focus on Docker as it has the lion share of the market.  If you want to learn more about the options, this article in Container Journal describes some alternatives.

Containers themselves come from multiple sources.  There are public depots (like dockerhub or Red Hat Marketplace) from where you can download ready to deploy images in your organization (think about it as downloading media – license is NOT included for commercial software).  Companies also create their own Container images using Docker tools.

They can be deployed in your own environment (private datacenter) or in Public Cloud environments.

When an organization is deploying Containers in their private datacenter, they are likely to use an orchestration engine like OpenShift, Docker Swarm or Kubernetes (but that’s not a requirement!).  Images can be deployed just like any other file and executed using “docker run” command (meaning they can only run wherever docker service is installed).

Containers can also be deployed in Public Cloud (e.g. AWS, Azure, GCP).  Here, you have a choice as well.  You can deploy a Container into Cloud Instances – essentially treating Public Cloud like an extension of your private datacenter.  You can also use Containers as a Service – where you simply deploy containers, but don’t have underlying infrastructure that you have to manage separately (like VMs or Cloud Instances).

So, when it comes to tracking Containers, no single approach is foolproof.

You can depend on inventory tools (ones that can collect software information from Containers), but that will only cover your private datacenter and Cloud Instances where the agent is deployed.  If the Containers are “short lived”, the agent may not be able to collect the information.  Having said that, the approach I am familiar with “talks” to the Container (Docker) service and will know about every Container that is deployed.

But, what about the Container as a Service scenario?

In this situation, you need to connect to the Container service to get information about what Containers are deployed.  You can also use the same approach in your private datacenter, connecting to the orchestration engine in your environment.  Good news is the orchestration engine will know about every container and image that it has deployed.

But you will get different information based on the approach you use.

When you use an agent that is capable of scanning the Container file system, you will collect inventory just as you do on any host machine.  Raw inventory will be collected and normalized by the inventory or asset management tool you have.
When you are talking to the orchestration engine, you get image information – something like this:

REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
<none>                    <none>              77af4d6b9913        19 hours ago        1.089 GB
committ                   latest                  b6fa739cedf5        19 hours ago        1.089 GB
<none>                    <none>              78a85c484f71        19 hours ago        1.089 GB
 
Can you tell what software is in each image?  Neither can I.

The good news is that image IDs are static – for example, if I have an image with Oracle DB 12c R2 Enterprise Edition, the image ID for that image is static.  If I apply patches to that image, I need to save it as a new image, resulting in 2 images (with 2 image IDs) for Oracle DB 12c R2 – one for the base package, another for the base + patches.

This provides a way to use that information for asset management.  But you need to have a lookup table for image IDs to match them with the software running in those images. At this time, I am not aware of any IT Asset Management/Software Asset Management tools can provide that mapping out of the box, so at least in the short term you will have to roll up your sleeve to manually allocate license consumption based on Image IDs of the Containers.

​Containers are here to stay – I believe they will become the norm for deploying software ((Microsoft’s MSIX packaging format is a form of Container as well) as we continue to evolve towards software-defined future and devops becomes the standard way to deliver updates.  They create new challenges, but the industry as a whole is evolving to support them.

​For decades, we have become used to buying IT assets and using them whenever we want.  Does it really matter the server we have isn’t running at full capacity 50% of the time?  In terms of overall efficiency, yes.  But, we already bought it, so the only thing we pay for is electricity, which is not top of mind for almost anyone.
Cloud computing changes that.
When you start using Cloud computing services (e.g. AWS, Azure, Google, etc.), you pay for what you use.  This means, anytime the compute resource is not running at full capacity, you are overpaying.  Yet, this is not something that we are used to tracking and unless your organization deployed Cloud Spend Management and/or Cloud Management Platform solutions, something we are probably unaware of.
But, what’s the big deal?  Aren’t these cloud compute services really inexpensive?  That depends on what specific Cloud Instance you are subscribing to and how long it’s running.
Let me give you a couple of examples.
Azure General Purpose B1S instance (1 vCPU, 1GB RAM, 4GB temporary storage) costs $0.0104 per hour (that’s less than a quarter per day!) running Linux or Windows.  Even after a year, that’s only $91.104.  So, how much can I save?  Not much.  If I have a hundred of these running that’s still not a lot.
But, how many applications can you run on such a system?
OK, let’s beef up the specs.
How about B4MS (4 vCPU, 16GB RAM, 43GB temporary storage)?  The price goes up to $0.166 per hour, or $1,454.16 per year.  If we multiply this by a hundred, the numbers are starting to get bigger.  But, that’s a hundred virtual machines, and the cost is less than having multiple physical servers + VMs (and virtualization software licenses and OS licenses).  But let’s say you can save 20% of that cost – for a hundred of these Cloud instances that’s about $29,000 per year.  What if you have a thousand of these?  Numbers start adding up quickly.
My recommendation is to get a Cloud Spend Management tool.  They really aren’t that expensive and they will pay for themselves.  There are many choices in the market.  You can even use native tools offered by Cloud Providers, but they are not designed to manage “other clouds”, so not a great choice, unless you are using a single Public Cloud vendor.