Eight reasons not to touch OpenStack with a barge pole

Or maybe you don't need that barge pole after all…

Sure, OpenStack is the "cool kid on the block" these days, and everyone's talking about how it's invading the enterprise space, taking over where virtualisation and public cloud now hold sway. That doesn't mean that you have to do it. If all the other companies were jumping off a bridge, would you do that too? Of course not. After all, you may have some very good reasons to hold off on implementing OpenStack.

You don't mind vendor lock-in

You understand why virtualisation is a good thing because you want to wring every last bit of resources out of your gear, so you're willing to pay for that. So what if that software doesn't do something you want it to? After all, the software vendors are the experts; if they haven't thought to put a feature in, it must be because you don't need it.

OpenStack is open source, which means, in this context, a couple things:

  • If there's a particular feature you want or need that's not available, you can simply build it yourself, or have someone build it for you. You're not locked into the vendor's roadmap.
  • If you don't like your current OpenStack vendor, as long as you're not relying on proprietary extensions that vendor may have added, you can change to another without changing how you interact with your systems.

You don't mind paying fees that grow when you do

No, those fees aren't a disincentive to growing. I mean, business costs money. You should expect to pay more to grow your business. So what if these are expenses for resources that haven't actually done anything for you yet, such as blocks of VM licences, or public cloud servers that are just used for development or testing. It's just the cost of doing business.

On the other hand, because OpenStack doesn't involve licence per-CPU or per-core licence fees, you can spin up or down the VMs you want in your private cloud as you like without having to fool about with licences.

You don't need to move any faster

You don't have any competitors, and even if you do, you're so far out ahead that you don't need to worry about coming up with products and solutions faster than you already do. They're your customers. They'll wait until you're ready to provide them with something. It's not like they're going to go to your competition.

With Infrastructure as a Service, on the other hand, your developers will be able to spin up a server to work on at a moment's notice, so when an idea or a request comes up, they can be working on it in minutes, not weeks or months. This is even truer if you have your own OpenStack cloud, so they won't even have to break out their credit cards.

You don't worry about performance and uptime

You use the public cloud because you don't want to have to worry about little things like uptime and availability. It's okay if your application shares a server with someone else's; you don't worry about the security risk. Who cares if your application slows to a crawl when they run a big job? It's still available, right? Oh, it's not? Well, it will come back eventually, that's the public cloud provider's problem and not yours.

One of the advantages of a private cloud is that you don't have to worry about some random person or company sharing resources with you, but there's still the issue of keeping things running. One of the options for OpenStack, on the other hand, is managed private cloud – also known as Private Cloud as a Service – in which the vendor is responsible for uptime, but you still get all the advantages of private cloud.

You don't want to change

You've been building applications this way for a long time, and you don't want to have to learn this new "cloud" stuff. Pets? Cattle? Applications that can go on even if servers crash? That's crazy. Who wants to do that? No you'll stick with good old reliable client server, thank you, and if something happens to a server you'll nurse it back to health, whatever it takes.

OpenStack, on the other hand, gives you the option to move into the world of resilient applications, though doesn't force it on you – if you want to spin up a VM and drop a client-server database on it, that's certainly an option. Or you can take advantage of an architecture that lets you simply shut down a machine that isn't working and spin it up somewhere else without your users even noticing.