Canonical recently released their Autopilot product. Autopilot fit within the bring your own hardware (ByoHW) market segment for private cloud. This product allow you to deploy and manage a full Openstack cloud. Canonical makes heavy use of its JuJu, MaaS and other in house (but open sourced) software. You can have a glimpse of how this product work in this blog post. This post also provide a glimpse of the complexity associated with the deployment and orchestration of an Openstack cloud. However, what is even more interesting is their pricing strategy and offering an insight on how they plan to "land & grab" the private cloud market.
Land :
For anything under 10 servers, it's basically free (but no support). Note that you need at least 5 server for a deployment and 6 for HA, so you have a little bit of wiggle room there but not much. With this strategy, Canonical tries to specifically target the biggest user segment of Openstack. You have to remember that most deployment (78%) are less than 100 nodes with 36% less than 10. Moreover, according to the survey most of these small deployment are DIY and use off the shelf Openstack solution (source or distro). We can deduce that there is a very small sales and profit potential in this segment as these users rarely have the budget. Most of the time they relies on in-house expertise and community support.
However, it is quite smart to try to hook them up by providing them with easy to deploy, robust and maintainable solution. As the user base is large there is a significant market potential for some of them to upgrade as they start reaching a certain size and their needs change the benefit from the paid solution arise. Obviously the objective is to use the land and grab approach with the least barrier (as in free) to entry possible in order to "land" the biggest Openstack user segment out there.
Grab:
If we look now at the pricing model, we can notice that they offer three type of payment plan per VM/Hour (0.003$/Hour), per Server/Year (1000$ / Year), or per availability zone. If you run less than the equivalent of 39 VM full time for a year per server (see chart below), you are better off going for the VM pay as you go model. This might be a smart choice if you tend to run big VMs such as the one for big data application. However, if run a hoard of small VMs you might quickly pay way more than the per server pricing plan, especially if you cram 1000+ VMs per rack.
The nice thing about this tiered approach is that it allows you to test the water with the pay as you go model and then switch to a more “classic” model if you discover that you will cross the 39 VMs per server ratio. Naturally heavy user will prefer the per servers model, but the dynamic one will be more easily adopted by a crowed already accustomed to the AWS cloud pricing model.
Moreover, even without a highly dynamic instance count, the per VM/H model should remain the preferred payment for the majority of small to medium Openstack deployment. As based on the survey, the vast majority (74%) of deployment have less than 1000 VMs. If we count that 78% of the deployments have less than 100 Nodes we can safely assume that the average number of VM per nodes is less than 39. As you can see, this pricing model is a very smart way of targeting the Openstack ecosystem by reducing friction to transition from free to a paying model.
Moreover, even without a highly dynamic instance count, the per VM/H model should remain the preferred payment for the majority of small to medium Openstack deployment. As based on the survey, the vast majority (74%) of deployment have less than 1000 VMs. If we count that 78% of the deployments have less than 100 Nodes we can safely assume that the average number of VM per nodes is less than 39. As you can see, this pricing model is a very smart way of targeting the Openstack ecosystem by reducing friction to transition from free to a paying model.
Retain
Obviously, when you cross the 75 servers line customer might want to switch to the availability zone pricing plan. However, based on the Openstack statistics, there is very few deployment with more than 100 nodes out there. As a result, this pricing model is probably there to show an natural upgrade path in pricing and support for potential customer. The objective is to demonstrate that they are able to service the complete spectrum of Openstack customers. While, I do not know yet how well Canonical fare on the integration/consulting side against Mirantis or other integrator out there, I suspect that they want to show a full end to end pricing model and solution in order to be taken seriously by the market. Moreover, it help reassure the customer that they can accompany them as their cloud needs grow.
No comments :
Post a Comment