# Cloud service providers: how to keep your options open

For Linux users, there's a new kind of computer on the market, and it's known only as *the cloud*.
As with the PC sitting on your desk and the laptop in your backpack and the virtual private server you rent from your favourite webhosting service, there are different vendors selling cloud computing.
The brand names are different than the hardware brands you've become used to over the years, but the concept is the same.
To run Linux, you need a computer.
To run Linux on the cloud, you need a cloud service provider.
And just as with hardware and the firmware that ships with it, there's a spectrum for how open source your computing stack is.

As a user of open source, I prefer my computing stack to be as open as possible.
After a careful survey of the cloud computing market, I've developed a three-tier view of cloud service providers.
Using this system as your guide, you can make intelligent choices about what cloud provider you sign up with.

## Open stack

A cloud that's fully open is a cloud built, from the ground up, on open source technology.
So much cloud technology is open source, and has been from the beginning, that an open stack isn't actually all that difficult to accomplish, at least on the technical level.
However, there are those cloud providers that feel the need to reinvent the wheel in a way that's proprietary, so it's easy to stumble into a cloud provider that's got a lot of closed source components mixed in with the usual open source tooling.

If you're looking for a truly open cloud, look for a cloud provider providing [OpenStack](https://opensource.com/resources/what-is-openstack) as its foundation.
OpenStack provides the software infrastructure for clouds, including Software-Defined Networking (SDN) through Neutron, object storage through Swift, identity and key management, image services, and much more.
OpenStack is, in the sense of my hardware computer analogy, the "kernel" that powers the cloud.
I don't mean that literally, of course, but if your cloud provider runs OpenStack, then that's reasonably as far down in the stack you can go.
From a user's perspective, OpenStack is the reason your cloud exists, and has a filesystem, a network, and so on.

Sitting on top of OpenStack, there may be a web UI such as Horizon or Skyline, and there may be extra components such as OpenShift or OKD.
All of these are open source, and they help you run containers, which are minimalist Linux images with applications mbedded within them.

Because OpenShift and OKD don't require OpenStack, that's the next tier of my cloud-based world view.

## Open platform

You don't always have a choice what stack your cloud is running.
Instead of OpenStack, your cloud might be running Azure or AWS or similar.
Those or the "binary blobs" of the cloud world.
You have no insight into how or why they work, all you know is that your cloud exists, and has a filesystem and a networking stack and so on.

Just as with desktop computing, you can have an "operating system" running on the box you've been given.
Again, I'm not speaking literally, and there's a strong argument that OpenStack itself is essentially an operating system for the cloud, but it's usually OpenShift that a cloud user interacts with directly.
OpenShift is an open source "desktop" or workspace in which you can manage containers and pods with Podman and Kubernetes.
It lets you run applications on the cloud much as you might launch an app on your laptop.

## Open standards

Last but not least, there are those situations when you have no choice in cloud service providers.
You're put on a platform with a proprietary "kernel", a proprietary "operating system", and all that's left for you to influence is what you run inside that environment.

All is not lost.

When you're dealing with open source, you have the ability to construct your own scaffolding.
You can choose what components you use inside your containers.
You can and should design your working environment around and as open source, because if you do get to change service providers then you can take everything you've built with you.

This might mean implementing something that's built into the (non-open) platform you're stuck on.
For instance, your cloud provider might entice you with an API management system, or a CI/CD pipeline, that's included in their platform "for free," but you know better. 
A non-open application that's "free" usually means it bears a cost in some other form.
One cost is that once you start building on top of it, you'll be all the more hesitant to migrate away for the knowledge that you'll have to leave behind everything you built. 

Instead of using closed "features" of your cloud provider, re-implement those services as open source for your own use.
Run [Jenkins](https://opensource.com/article/19/9/intro-building-cicd-pipelines-jenkins) and [APIMan](https://www.apiman.io/latest/) in containers.
Find the problems your cloud provider claims to solve with proprietary code, and then use an open source solution to ensure that when you leave for an open provider, you can migrate the system you've built.

## Open source computing

To too many people, cloud computing is a place where open source is incidental.
In reality, open source is as important on the cloud as it is on your personal computer, and on the servers powering the Internet.

Look for open source cloud services.

When you're stuck with something that doesn't provide source code, be the one using open source in your cloud.