The True Meaning of "Open Cloud"

*

Originally published at The New Stack.

* What exactly does open mean when it's applied to the cloud? In the modern software engineering world, there's a tendency to value "openness" over all else, and sometimes we act as if the "open" in open source can be just as easily applied to other parts of the engineering stack. But open source and open clouds are totally different concepts, even if they both contain the word "open." Even if a cloud provider claims to have an open cloud, it should be obvious to everyone that the cloud infrastructure is not maintained by a global community of volunteers who do not monetize their efforts. Cloud "openness" is often misunderstood, sometimes because companies intentionally mislead us about what is and is not open, sometimes because as an industry we try to oversimplify very complex offerings and technology. Word choice hurts us, too. The linguistic similarities with "open source", and the fact that "open" and "closed" are usually presented as binary options rather than a spectrum, make it easier to misconstrue the realities of an "open" cloud. Oversimplifying and/or misunderstanding what openness really means in the context of a cloud environment can lead organizations to make poor decisions about technology choices, leading to wasted time and wasted money. Here's what organizations should consider when they think about how to evaluate how open a cloud is - and whether or not that even matters.

"Open" is a spectrum

The openness of any platform, cloud or service is a measure of how locked in customers are, which itself is little more than a calculation of how much it would cost, in terms of time, money and headache, to migrate off of the platform or cloud. Cloud providers might talk about being "open", but there are no completely open clouds. After all, while talking about how open their clouds are, all the cloud providers charge for egress traffic. This can't be just about their own cost of maintaining the underlying technology: ingress traffic is free. If the dedication to a truly open cloud were real, moving out would be just as free as moving in. One of the problems with the term "open cloud" is that it encourages people to think of "openness" as a binary: either a cloud is open or it is closed. But openness is a spectrum, not a binary. The extremes of completely open or completely closed don't exist: Migration costs are never zero. It is also never impossible to migrate off a cloud or platform, though it can be extremely expensive.

What factors make a cloud more or less open

So how do we evaluate where on the openness spectrum a particular cloud is? The most open of open clouds will always have the following characteristics:

• Built on open source
• Facilitate data openness, including having tools that make it easier to access, process and move data
• Use open APIs, use standard interfaces and adopt open standards.

However, even a cloud that meets all of those requirements is not fully "open", in other words, the cost of migrating off that cloud would not be zero. Here are the factors that organizations should evaluate to see where a particular cloud or other platform falls on the openness spectrum:

How much glue is holding the open source components together? Just because a cloud is based on open source does not mean that creating the same experience or functionality elsewhere is easy. There are always custom, proprietary scripts holding everything together and making the open source software easier to use and more reliable. The more proprietary glue the less open the cloud.

Data portability. Data has gravity. Moving data can be both time-consuming and costly. How easy it is to move data out of a cloud environment is one of the most important factors when determining how open the cloud is.

Additional services. All of the cloud providers offer all kinds of add-on services, from secrets management to monitoring and logging. Each service you use increases your lock-in, making it harder for you to migrate elsewhere. The more proprietary services you use, the less open the cloud is. Some services will be more open than others, and it's useful to evaluate openness not just of the entire cloud provider but also of each individual service the organization uses.

What skills are required? Lastly, there is a skills component to cloud openness. Not all organizations have highly skilled engineering teams. The more sophisticated your team, the easier it would be to move away from any particular cloud and the less reliant the organization is on managed services.

Making better choices

When organizations buy into the idea of a binary open/closed cloud, they are skipping over all the details about what makes a cloud more or less open, and ultimately failing to thoroughly evaluate what is and is not important for their organization. Good decision making always requires a complete understanding of both the available options as well as the organization's strengths, weaknesses and priorities.

It would be a mistake to assume that the more open a cloud is the better. For many - probably most - organizations, worrying about cloud lock-in is a distraction that can prevent the engineering team from taking advantage of the cloud's agility, speed and cost savings. Sure, a few companies might derive a competitive advantage from infrastructure management, but they are rare. In most cases, organizations who insist on making their cloud environment as open as possible find themselves spending valuable engineering time managing open source software and rolling their own services that could be purchased off-the-shelf from the cloud provider.

Instead of thinking about whether or not a cloud is open, an engineering leader should evaluate your organization's priorities: Where is openness important? Where is it not? How well do the services you consume from your cloud provider fit with your organization's priorities? That will give you a better place to start when evaluating which cloud provider has the right balance of open source, proprietary programs, out-of-the-box services and barriers to migrating away and ultimately lead to better cloud-related business decisions.