Why open infrastructure matters in the cloud | Opensource.com
Why open infrastructure matters in the cloud
When reading a recent article by Red Hat CEO Jim Whitehurst, I was struck by a comparison made between OpenStack and the interstate highway system. The article in Wall Street and Technology, called "OpenStack: Five things every executive needs to know," mostly focused on the high points of where OpenStack is in its development cycle. But the highway analogy stuck with me.
Part of what made the interstate highway system successful was its standardization and its open nature. "Unlike the early days of the railroads, where track gauges differed and companies refused to interconnect their networks, interstates are open to all who wish to use them," Whitehurst writes. Signage, road widths, and most other components of the system remain generally familiar as one moves from state to state and region to region, with some minor but acceptable variation.
Whitehurst makes the case that many advances we see in computer technology come not from performance advances, but from increasing openness and common standards. As more and more technology moves to the cloud, the importance of openness and compatibility is just as important, to ensure that computing in the cloud remains a rich environment for rapid innovation. The openness of the infrastructure underlying the cloud may be one step further removed from the end user, but it is still of great importance.
But why does open source matter when we're building the infrastructure of the cloud? Let's be honest. To most people, even to most developers, infrastructure isn't sexy. We rely on it every day, but honestly, all most of us care is that the infrastructure doesn't break.
In the real world, though, infrastructure does break. But those breaks aren't always technical glitches. Building your business around infrastructure you don't control means that you are dependent on the companies running that infrastructure. If something changed that required you to move your infrastructure to a new company, would you be ready? How much time, energy, and expense would go into preparing for the move?
I have no beef with any particular company offering infrastructure as a service (IaaS), so I won't pick on one. But let's instead look at the notorious "Company X," who is is running my hypothetical cloud. I am hosting several mission-critical application, running on virtual machines which my support engineers have spent countless hours tweaking all the way to the operating system level to meet my needs. My websites, my applications, and my data all live on Company X's infrastructure and are managed on their proprietary interface.
- What happens if tomorrow, Company X decides that the cost per gigabyte of storage or hour of processor time should double?
- What if I live and work in a country who's government doesn't have the best relations with the country where Company X is located? What happens if political unrest pulls the plug to the outside world, or an embargo prevents me from working with them anymore?
- What happens if I rely on a legacy product that works just right for me, but Company X pulls the plug on support for that configuration?
- And what happens if Company X simply folds?
If my infrastructure is managed with proprietary software, I'm going to be in for a world of hurt if I try to move. Portability matters. And openness matters. This is why infrastructure projects like OpenStack matter, particularly to the little guy. If I wanted to jump ship to Company Y, or even rent space in a datacenter to start managing my own infrastructure, I'm going to be able to do so with minimal pain.
I'll have a selection of infrastructure providers to choose from if I don't want to do it myself, and I'll be able to purchase support from a vendor of my choosing. I'll have a community of support to ask questions to when I need help. I'll be able to edit the source myself of my IaaS tool myself to meet my needs. And, I'll be able to evaluate the newest version before I make the switch, with no arbitrary time limits or other restrictions, because I can test it on my own hardware at my own pace.
The point here isn't to pick on closed source infrastructure providers. They provide a valuable service, and often times provide a lot of open source tools further up their stack. The point is that maximizing user choice has value to a lot of customers, and that the ecosystem of infrastructure options is better when it's open.
Not everyone manages infrastructure for a living, but we all depend on it. And I feel better when I know that the infrastructure I rely on is open.