4 Considerations When Pricing Container Services

Another week, another post about container services for MSPs!

It’s exciting to see this series continue for 9 segments so far, with many more to come! Thus far we’ve spent A LOT of time talking about the technical aspects of container services for MSPs. We’ve talked about things like container networking, supported platforms, running containers using Azure Container Instances, and much more! If you’re new to this series, have a look at the list below to see what we’ve covered so far.

If you’ve been following this series regularly, you’ll know that the plan for this series has been to ultimately look at offering container services through the lens of an MSP. Mainly, by answering the question of how can MSPs leverage and solve customer problems using container services? We’ve spent most of the time thus far on technical how to, and for this segment, I want to do something a bit different. Today we’re going to talk a bit more about the business side of container services, mainly pricing considerations. This segment will serve to get you to start thinking about how you want to price container services before we get back into some more technical items such as more container networking and ultimately Kubernetes.

Like previous segments, let’s take a look at where we’ve been before moving on.

The Definitive Guide to Containers for MSPs

Part 1 – What are Containers?

Part 2 – Platforms for Running Containerized Workloads

Part 3 – Introduction to Docker

Part 4 – 4 Pro Tips for Working with Docker

Part 5 – How to Run Linux Containers on Windows Server 2019

Part 6 – How to Create Persistent Docker Containers

Part 7 – Docker Container Networking – Part 1

Part 8 – How to Setup a Linux Container Host

Part 9 – How to Run a Container in Azure with Azure Container Instances

The Basics of Pricing Container Services

Before I go any further on this point, remember its still VERY early days for containers. So, what works for pricing container services today is certainly subject to change, just like any new service you bring on. What I’ve seen thus far in the industry is that many MSPs default to treating (and pricing) container services like they would VMs. It’s not wrong to price it that way if your customers are consuming them like a VMs. However, remember the life-cycle of a container. Historically containers start, execute their running workload, and then terminate. If you’re going to price them like a VM, then that’s a lot of time (potentially) that you’re billing the customer for that the container isn’t running.

Again, it all depends on the workload inside the container. It may be entirely possible that you’re running a 24/7 persistent workload inside of a container(s) for a customer. So, in that case it may make more sense to treat the container like a VM. I guess what I’m getting at is that it really depends on how you’re going to serve up container services to your customers, and for a business that thrives on the cookie-cutter approach, it works best if we can define a few broad strategies here.

So, with that in mind, before we go much further let’s look at this from the perspective of a pricing model that is already defined. Running containers in Azure Container Instances.

Pricing for Azure Container Instances

Sometimes the best place to start is to look at a model that is already defined. We’ll start with Azure Container Instances. Like all things in Azure, Container Instances are usage-based. If the container is running, you incur a cost. If you’re storing data associated with a container, you incur a cost….etc..etc. What do these prices look like? The highlights from the official pricing documentation are listed below:

• Compute Costs for Container instances are priced at the container group level. (Could be more than one container in a group)
• Compute Resources (CPU and RAM) are associated with the group
• The cost incurred is determined by the amount of time (in seconds) said compute resources are in use
• A public IP may be needed which would be an additional cost
• Storage used by the containers will incur cost no matter if the container(s) are/is running or not.

As an example:

Let’s say you have a container group that runs a Windows-based container for a customer. The workload needs 4GB of memory and 2 vCPU. A static public IP is needed and a small amount (50 GBs) of blob storage is needed. The customer needs to access it for 12 hours a day (half the month). According to the Azure Pricing Calculator, the costs would break down:

• $6.41 a month for memory time
• $29.16 a month for vCPU time
• $31.10 a month for a Windows Software Charge (licensing)
• $2.08 a month for storage (and storage transactions)
• $3.65 a month for the public IP Address

The total for this comes out to $72.40 a month. You’ll then want to tack your margin and support services on, which we’ll assume comes out to +35% combined in this example.

$72.40 + $25.34 = $97.74 monthly cost for the customer.

Again, simple example here but it gives you a good idea of the costs involved with hosting container services on an existing hosting platform. Realistically, costs for on-prem/colo hosting won’t have to be broken down so granularly, but they’ll need to be accounted for somewhere.

Let’s look at a few more options that are more self-hosted

Pricing for MSP Container Services Based on Run Time

Instead of using Azure, for this example, we’ll assume you’re running on your own hosted infrastructure. I’m not going to come up with a component for component cost breakdown for this example, because you already know what that looks like in your hosting environment, but let’s say that for the same workload (4GB RAM, 2 vCPU, 50 GB Storage, Networking) you can serve the customer for $80 a month (margin included) for 12 hours a day. However, maybe the customer wants to run the workload at variable times for different lengths of time? That breaks this pricing model for your own hosting platform, doesn’t it? This is where your own time-based model comes into play.

Based on the example cost/margin pricing I just mentioned we know that $80 a month (for 12 hours a day) comes down to $0.00358/minute (rough math). Knowing this you could run a script when a container starts, and then a report monthly to determine how many minutes a specific container ran and then bill accordingly. In a future segment, I’ll be sure to include some examples of a script that could help in this situation.

Pricing for MSP Container Services Based on Number of Containers Run

Moving to an even less granular option, you could just simply bill based on the number of containers that have been run (regardless of duration) throughout the month. In this sense, you treat the containers like VMs from a pricing perspective. You likely already have costs associated with VMs of various sizes for your customers. I’ve seen some MSPs simply say, OK….. this container is X size, and if you powered it on at all during the month, the cost is $X, just like if it was a VM. While there is a little give and take (profit/loss) each direction here, you could price on the conservative side to make sure you still make a healthy margin. The benefit here, of course, being simplicity and the only things needed really are prices, and a script to determine which VMs were provisioned and run in a given month. Like the previous example, I’ll be providing a script for this in a future segment.

Pricing for MSP Container Services at the Container Host Level

Another route I’ve seen some MSPs go is to not worry about the container at all. The MSP simply bills the customer for the container host itself just like they would any VM. The customer can then carve off containers and consume them up to the amount of resources provisioned to the container host. Again, simplicity is a benefit here, but an additional added benefit is the customer just pays for a VM like they most likely have been doing with you all along.

I’ve also seen a bit of differentiation here based on the type of container needed. If a customer only needs Windows Containers, Windows Server standard edition can be used as the container host’s operating system, which lowers the licensing costs. Microsoft allows you to run an unlimited number of Windows containers on a container host. If they need the added isolation that a Hyper-V container provides, then that customer needs Windows Server Datacenter edition, which then increases the costs to you. This is because Hyper-V containers are licensed like VMs. With Standard Edition Windows Server you can run a maximum of 2 Hyper-V Containers, and with Datacenter Edition it is an unlimited number. As such, you could sell two “tiers” of container services to your customers, with this in mind. Not only do you have added simplicity, but some extra flexibility as well.

Wrap-Up

Again, this is by no means a comprehensive list of all the ways MSPs could price container services. However, it does serve well to give you an idea of the components involved and to get you thinking about how the pricing would work in your own hosting environments. With this information, you can now start taking some of the information provided in this series to start crafting a go-to-market strategy for basic container services. We’ll be covering more in a future segment with some advanced services, but this should be enough to get you started.

What about you? Have you looked at pricing container services yet? Do the options above line up with your thought process? Have you come up with a different option? Let us know in the comments section below! We’d love to hear!

Thanks for reading!

Want to learn more about setting prices for cloud services more generally? Read our latest eBook especially for MSPs:

Free eBook: Azure for MSPs – How to Sell Cloud Services