With all open infrastructure components; whether it’s Ceph, OKD, Cumulus, Kubernetes, or OpenStack, I often get questions about the difference between software support and infrastructure support. ‘In what way and at what level am I able to support my open source infrastructure?’ ‘Can I support my open source infrastructure with software support only, or do I need a higher level of support that covers my whole infrastructure?’ ‘Why would I need infrastructure support when I already have software support in place?’ And vice versa: ‘Why would I want software support when I can get infrastructure support at Fairbanks or 42on?’

Generally, customers talk about four ways to run their open source software:

• Without any support: upstream community versions;
• With software support subscriptions;
• With infrastructure support (often used in combination with software support);
• Fully managed.

So, let’s have a look at what’s what.

Without any support

The first way to run your open infra software is to use the upstream versions, as released by the various communities. This software is open and free to use but will often lack an extensive support process. Bugs and feature requests are prioritized by the community and often treated as suggestions. For enterprise purposes to run the community version of software, requires your own support organization to be able to alter code if you find yourself in a situation with issues that are not resolved by the community (yet).

Software support

If you cannot resolve bugs in the software and want to get some SLA on bug fixing, numerous companies provide technical support or break/fix services for open software products. It often includes unit testing of all changes, integration testing of a release, and packaging the software in a full stack of vendor-supported open software tooling. But also, SLA-based bug fix support. Examples are Canonical Ubuntu Linux as the enterprise-released and supported version of the open Debian Linux. Or Red Hat Enterprise Linux for open Fedora Linux.

In other words: When your software fails or when you are having software bugs; you will get help from the software supplier. You might recognise this when you have a support service for an ERP-system for instance, or when you have a problem with a workstation. We advise you to get software support subscription from you preferred open source vendor.

Infrastructure support

But what if your cloud environment is down, yet the software is working correctly? Let’s say you are working with Ceph, multiple machines or disks have failed causing Placement Groups to become inactive, or when monitors are no longer reaching quorum. But you cannot find any problem with the Ceph software itself. You will have to troubleshoot all kinds of components to see what’s wrong and where the problem might be.

Or what if you like the open source solution, but you don’t know how to optimize the integration in your business architecture?

This is where infrastructure support comes in. Where software support stops, infrastructure support starts. With this support, the supporting company will work on the correct working of the software in your use case, in your infrastructure. Whether it’s a failure in the software, in the infrastructure connections or in the infrastructure itself. At Fairbanks and 42on, we provide this kind of support.

Hosted or fully managed

So, whether you chose no support, only software support, or even infrastructure support, your team still has to include skilled engineers to maintain your open source infrastructure on a daily basis. With this fourth model, a hosted or fully managed model though, you don’t need a team to keep the infrastructure running and up to date. An external company manages and is responsible for the uptime of the full cloud or storage infrastructure for you. Your teams can focus on providing the hardware layer and on managing the application, workloads, and data on top of the cloud.

Which model

So, the support model you need fully depends on how your teams are made and for what purpose the solutions are used for. Tons of companies run open source software without support and are successful in doing so. Some companies acquire software support, while others purchase infrastructure support or choose hosted or fully managed services, so they can focus on their own added value.

Software support and infrastructure support are often combined. Companies want to rely on the Long-Term Service version of the software vendor like Red Hat, Canonical, or Suse but also want a company that supports them with outages and/or when the teams cannot solve issues themselves. And can assist in the troubleshooting and log reporting often needed for bug support.

The optimal support model, therefore, completely depends on your internal SLA, as well as your team focus and your infrastructure. There are all kinds of factors, so it’s hard for me to say: ‘you need only this or this,’ or ‘you need the whole package’ in a general manner.

When you would like to know more about what support model fits your company the best; please let me know and we will find out what works.