OpenStack distributions: How to choose the right one?

Choosing the right OpenStack distribution is essential to the success of an OpenStack project at every organisation. When selecting one, organisations should always follow certain criteria. Is it possible to operate the considered OpenStack distributions economically? How easy is it to deploy them? Can the organisation upgrade its production OpenStack cloud without affecting the workloads? Everyone planning to deploy OpenStack should ask themselves these questions. And there is always more criteria to consider.

In order to facilitate the OpenStack vendor selection process for the organisations, we have recently published an OpenStack distributions comparison website. It highlights the key differences between three leading OpenStack platforms: Canonical’s Charmed OpenStack, Red Hat OpenStack Platform and Mirantis Cloud Platform. Now, in the following blog, I am going to describe some tips which organisations should follow to make sure that they choose the right OpenStack distribution.

Good economics

One of the primary goals behind cloud environments is better economics compared to using proprietary hardware. Thus, it is important to make sure that the selected OpenStack distribution can bring the costs down. Avoid OpenStack platforms which are hard to deploy, maintain and upgrade. Struggling with basic operations will significantly increase costs. Also, plan the expenses carefully, including conditions like yearly growth rate. Make sure that the pricing model is clear and predictable. 

100% open source

While OpenStack itself is open source, the installers provided by the vendors as part of their distributions, may not be. As a result, additional costs may apply due to the licenses. This leads to situations where organisation have to pay for the OpenStack distribution before even trying it out. Moreover, all types of environments in use, including staging and development environments, have to be covered by the license too. OpenStack distributions which are 100% open source provide better economics and flexibility for organisations.

Predictable release cadence

Although the release cadence of OpenStack is fully predictable and well documented, not all distributions follow the upstream. Having support for the latest stable upstream release as soon as possible is important for various reasons. For example, there may be some features in the upstream release that are important for the organisation. Or there may be bug fixes which are critical from their point of view. Choosing an OpenStack distribution with a predictable release cadence enables proper planning and helps stay in sync with the upstream.

Long enough support time

Support services are essential for production environments, especially those where SLAs (service level agreements) apply. But no single vendor will support some of the old versions of OpenStack forever. Although there is always an option to upgrade or re-deploy, under certain circumstances, it may be beneficial for organisations to stay with the current version. For how long the vendor will provide support services, becomes a decisive factor. Therefore, always make sure that the OpenStack distribution you select provides support coverage for as long as you need it. 

Support for upgrades

Some organisations want to stay supported with some old OpenStack versions for as long as possible, while the others want to upgrade on a regular basis. Whether they actually can upgrade becomes critical for them. OpenStack upgrades are known to be complex and many commercial distributions do not support them. And even if they do, the entire process is very complex and has to be executed manually. Thus, choosing an OpenStack distribution that provides support for fully automated upgrades is essential for the success of the cloud team.  

Simplified operations

An OpenStack deployment is usually just the beginning of the journey. Later, organisations have to maintain the cloud on a daily basis. This includes operations like scaling the cluster out or recovering it from failure. While most OpenStack distributions do not provide any mechanisms to simplify operational tasks, enforcing users to execute them manually, there are some that do. Abstracting complex operational tasks by hiding the entire logic behind them offloads operations teams and thus, results in cost savings as well.

Flexible technology choices

OpenStack is a flexible cloud platform, offering support for various hypervisors, SDN solutions and storage plugins. However, many OpenStack distributions are usually tied to a single stack. Avoid this trap as you may need to re-platform or move to a heterogeneous environment in the future. Always go with an OpenStack distribution which you can adjust to work with new technologies.

Learn more about various OpenStack distributions

If you want to learn more about various OpenStack distributions and differences between them, visit our website. You will find there a detailed comparison of Canonical’s Charmed OpenStack, Red Hat OpenStack Platform and Mirantis Cloud Platform.

To get in touch with us about Charmed OpenStack, click here.

What is OpenStack?

Try OpenStack.

OpenStack deployment made easy

Ready to move from expensive, proprietary virtualisation to OpenStack? Canonical designs, builds, operates and supports OpenStack private clouds.

Move to OpenStack ›

Newsletter signup

Select topics you're
interested in

In submitting this form, I confirm that I have read and agree to Canonical's Privacy Notice and Privacy Policy.

Related posts

Telefonica Brazil selects Canonical’s Charmed OpenStack for industry-leading cloud-based online charging system

13th January 2021 – Canonical, the publisher of Ubuntu, today announced that its Charmed OpenStack has been selected by Telefonica Brazil to – in a first for...

OpenStack for telcos by Canonical

Learn how Charmed OpenStack offers telcos fast networking, security, stability of performance, and optimal SDN and storage options.

Improving CLI output with jq

Welcome back to our series on MAAS CLI operations. In our previous post, we learned how to acquire and deploy machines using the MAAS CLI. It was also evident...