We know OpenStack is hard. But why?
Earlier this month, Christian Carrasco gave a keynote address at the OpenStack Days Silicon Valley conference, discussing six factors behind OpenStack evaluation and deployment failure — and how to solve those problems. As Cloud Advisor at Tapjoy, Carrasco is architecting a 550-million-user cloud based on both private and public resources. He also has a history as CTO of a private cloud hardware company and two other startups focused on cloud technologies, so he brought a lot of insight into the causes of failure, pinpointing six primary points of failure.
Lesson 1: Leave the dogma at home
Dogmatic views, or beliefs accepted as fact without doubt, are blinders, he explained, and they can come from a variety of sources, including bad previous experiences with technology. For example, Carrasco’s experience with OpenStack five years earlier had been a negative experience because the platform just wasn’t ready. Fast-forward five years to 2016, and it’s now rock-solid for many applications, including his.
However, if dogma had prevailed, trying OpenStack again might have been out of the running. Keep in mind, though, that rebranding old technology as new, or new technology as old, or even rebranding fake technology as its legitimate counterpart can lead to a poor experience that gets associated with that real technology. (See Lesson 5.)
Lesson 2: Fear, doubt, uncertainty, and doom (aka FUDD) can cause problems
Remember when Linux was first launched? If you do, then you probably also remember the a proliferation of scare tactics. Your world will end if you use Linux! Nothing will work! Licensing is too confusing! Cats and dogs, living together, total chaos!
OpenStack has seen the same kind of FUDD. Every year, independent publications, public entities, and skewed statistical reports predict the death of OpenStack. And yet, OpenStack keeps on keeping on, taking over the private cloud market.
Lesson 3: Find the right distribution
The third reason Carrasco covered was the “You picked the wrong trunk” scenario. The latest version of open source software such as OpenStack is called the “trunk”, a base repository of code. The thing about trunk is that it requires lots of tweaking and the modules aren’t always in tune with each other. Community Linux trunks can have some configurations tweaked but not all, and it still requires a level of expertise, so deploying from trunk is not for less-experienced engineers.
Lesson 4: You are not a full-stack engineer
In today’s world, where personnel often have to fulfill multiple roles, many engineers are being told they have to be “full-stack engineers.”
Carrasco, who has worked the full stack and still says he’s not a full-stack engineer, believes full-stack engineers are myths, and he makes a great argument for his belief. It’s really hard to be a full-stack engineer, he says, because you have to be proficient in every realm of the stack — and it’s not just the software. Just being proficient in software stack is difficult, but when you throw in the hardware side, as well as networking, security, and so on, being an expert in everything is a monumental, if not impossible, task.
Organizations need to be aware of the skillset of the people leading the OpenStack deployment and be sure they’ve got all of their bases covered.
Lesson 5: You thought OpenStack was a better buggy for your horse
OpenStack isn’t necessarily a better buggy, or a cheaper method of doing something, or the open source way of doing something. Carrasco says it’s more of a paradigm shift, a new methodology that is still evolving, in the way data centers operate. And the reality is that sometimes this methodology isn’t ideal for traditional businesses.
Lesson 6: You didn’t have a sufficient team
While the rumotrs that you need dozens of experts to successfully deploy OpenStack is an exaggeration, you’re likely going to have problems if you try to deployed it alone, or with a very small team that isn’t ready to deploy data center technology.
If you need help with your OpenStack deployment, there are plenty of options available for design, architecture, and verification of your stack, from automated tools to semi- and fully-managed services.
Along the same lines, some companies aren’t really ready for OpenStack yet, and it may not be economically feasible for a small company to hire a cloud team, purchase hardware, and rack up costs.
On the other hand, some companies lend themselves well to deployment, such as companies that were born online, are making the move to online, or are ready to stop using buggies and be committed and engaged to moving to the next generation of cloud computing.
OK, so what do I do about it?
Carrasco offers two major solutions to help prevent OpenStack deployment failure.
The first thing Carrasco asks companies he advises is “Where is your Cloud Officer?” If you’ve made a multi-million dollar investment in your cloud and it’s a side project of some other team in your company, that’s not a recipe for success. “What happens to clouds that become orphaned?” he asks. “They become security risks. They become a headache. Nobody wants to work with them, and they vanish,” he says. There needs to be real ownership for your cloud to succeed, and a Cloud Officer will protect your cloud, prevent vendor lock-in, and bring the cloud in line with the organization’s initiatives.
The second solution he suggested is all about vendors. Despite the open nature and coopetition of OpenStack, according to Carrasco, the status quo consists of both public and private vendors fiercely guarding their territory and coming up with creative ways to lock users into their service or their cloud technology, etc., and few companies are creating ways to enable outside operability.
Carrasco’s ultimate vision for a solution is to adopt what he calls a hyper-converged cloud. In this architecture, you have your cloud and your assets powered by multiple vendors — whoever you want to choose to power your cloud. This structure has an added advantage of opening possibilities for niche providers of services not offered by private or public clouds.
The point is not about technology, but about people being able to own their assets. Carrasco is instituting this concept successfully now at Tapjoy, but for this concept to work, interoperability standards are key. Oh, and to those who’d say it’s late for standards, Carrasco points to market research that shows cloud technology is still a tiny speck on the radar when compared to the market share of other tech industries.
So stop trying to make a better buggy, Carrasco says, and focus on making the next-generation cloud.