OpenStack offers users multiple benefits, and it’s not difficult to see why the idea of building your own cloud with free open source tools appeal to many companies. However, anyone embarking on an OpenStack project needs to be realistic. During our years of building and deploying OpenStack cloud environments, we at Mirantis have seen a lot of wishful thinking – which can lead to unrealistic expectations. Following these 10 steps will ensure that you’re heading in the right direction.

1. Be prepared to pay

Very often we hear: “Why do we need a budget for this? We’ll just implement the code off the repo. There’s no license fee.”

That last bit is true. There’s no license fee to run OpenStack, but open source software doesn’t just appear out of nowhere, especially for a project as large and complex as OpenStack. Hundreds of people get paid to work very hard to improve the code, which changes constantly, so the latest version of one component requires you to bring in the latest version of everything else.

The problem here is that the latest code is always unstable, and critical bug fixes happen at the speed of the community, not yours. You are going to need someone to fix your bugs, and manpower takes money. Thus, open source code is free at any given moment in time, but it requires a budget and dedicated resources.

2. Involve people

If your entire cloud is small enough to fit on your laptop, you might be able to do it yourself. If you’re looking at a medium or large cloud, however, the project is going to involve a lot of people. Most companies implement clouds for reasons that aren’t simple; you must understand what everyone else needs — not just you — in order to do this right.

Explicitly document your use cases so that you can figure out whether you need a public, private, or hybrid cloud. Is your workload multitenant, long-running, short-running, dedicated, ephemeral, stable, bursty, or maybe even all of the above? Maybe the solution to your problem isn’t even in the cloud. Look at your legacy applications. Do they belong in the cloud, or do they need to continue on your existing infrastructure? None of these decisions can be made in a vacuum.

3. Be clear on terminology

You may believe that everyone understands the terminology, but it is critical to understand the whos, whats, whys, whens, wheres, and hows — collectively.

Consider the following sentence we heard in a planning meeting: “We built a service to support the service, but when we had problems with the service level, we called services.” Or, look at all the chatter on the OpenStack forums about the actual meaning of the word “type.”

Take the time to understand what your constituents mean in precise terms, because there is no common understanding — even with common words.

4. Accept that legacy systems don’t just go away

There’s a reason COBOL programmers still have jobs. Legacy applications don’t just go away; that’s just the reality. Recently, a hyper-enthusiastic system admin told us: “We’re just going to build a cloud and move everything over.” Maybe this will work, but not quickly. Some legacy systems, such as certain data storage, transactional, financial, and insurance applications are just not ready to move to cloud, especially if business rules have not been well-documented.

5. Consider the workloads you’re moving

Some people think that all you need is load balancing when moving to the cloud. This particular fallacy comes from thinking of the cloud as a giant router that just shifts stateless traffic to where it can run the fastest. Think about what workloads you’re moving to the cloud. Is it a dev-test environment? Can you ramp up or ramp down? Can you shut it down in an emergency? Do you need a single component or multiple components? In most cases, you can’t scale an application just by cloning its elements; not all constituent services can maintain consistency across replicas unless they’re architected from the get-go.

6. Collaborate with developers

In OpenStack, applications can exercise far more control over the platform they run on than in a conventional environment. This is a shift in the operator and developer relationship, and the two roles need to play nice with each other.

Operators build with OpenStack so developers can self-service the infrastructure, but this doesn’t mean they are cannibalizing their own role. They need to carefully give the developers just enough choices to make them successful. Create a menu — don’t give them free reign. They also need to arm developers with more expertise to properly architect and operate the solution.

7. Don’t presume your staff has the required skills

We often hear: “Our staff has the skills. It’s just like Linux.” Sure, if your organisation is endowed with source-code masters for IP networking, hypervisor resource management, storage redundancy and optimisation, source-code management, security and encryption, driver optimisation, distributed application architectures, and any number of other technologies involved in OpenStack, you may be right. Chances are, though, you’re missing one or many of these skills, and your staff needs to know that.

Everyone can use Linux, but not everyone’s a kernel engineer. You can become the source-code master who knows everything, but not overnight.

8. Build a proposal

“Cloud introduces great efficiencies. It’ll pay for itself.” Go ahead and try to get that past the CFO.

More than likely, you’re going to need new hardware and it’s not going to be the light and cheap stuff. And smart people don’t work for nothing. You’re going to need to train the people who don’t know everything they need to know. Oh, and do you also have a vacant, water-cooled data center nearby?

You may also need a new business model. Your existing infrastructure was funded with a set of assumptions about utilization by different functions and business owners – assumptions that likely no longer hold true. Where are your users going to get the money to support the cloud?

We often see companies start small and grow a business case with Mirantis OpenStack Express because it can help in making budgets concrete, manageable and predictable. The ones that have the most success understand their users’ economics and the value of their cloud, and propose a plan accordingly.

9. Have plans in place for crashes

A common misconception is that the cloud fixes itself. With the right monitoring and maintenance, it can, indeed, fix itself — sometimes. But you need to make sure you have the right monitoring and the right redundancy, especially for alerting when capacity thresholds are near. You might not know it’s broken until it doesn’t fix itself; then you’re going to get that 3:00 A.M. call. Remember that engineer who knows everything? She’s not always going to be available. If you prepare for the unexpected, you won’t get caught off guard.

10. Embrace failure

Finally, there’s the romantic old-school belief that failure is not an option. In fact, when it comes to cloud, failure isn’t just an option — it’s a core design principle. Fail often and fail fast, so you can move quickly. Just make sure that your systems and applications are prepared for the moment when something goes down and they have to adjust. Then you will really feel the benefit of OpenStack as your systems keep going even when things aren’t going to plan.

OpenStack undoubtedly offers businesses a world of opportunity for their IT infrastructure, providing a solution that is scalable, flexible and cost effective. Understanding your business’ needs and what’s involved in an OpenStack deployment will help to build the versatile, agile and resilient cloud system that your business wants - without making any of those commonly made mistakes.

Rajiv Sodhi is the Managing Director for EMEA at Mirantis, where he leads sales operations and supports customers deploying Mirantis OpenStack. Rajiv joins Mirantis from Red Hat, where he quadrupled revenues as the Benelux Country Manager. Prior to Red Hat, Rajiv spent ten years on the proprietary side of the business at IBM Netherlands. Follow him on Twitter at @SodhiPuntNL.

Image credit: OpenStack