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.