7 Questions to ask when shopping for your Cloud Platform (or OpenStack)
There are two kinds of people in IT/DevOps today: those who are already planning and eventually implementing cloud strategy, and those who are going to be doing it soon. The options you’re faced with are dizzying, often contradictory, and usually dangerously expensive. With all the choices in front of you, what’s the best way to get focused and find the ideal path forward? If OpenStack is the answer (or not), what’s the question?
There are a lot of questions, actually. Determining what you need from your cloud will drive what platform you deploy on. Considerations like budget, expected performance, and project timeline all have to be carefully balanced before plunging ahead. Broadly speaking the platform options range from using someone else’s public cloud to building your own private cloud from scratch. Where you land on that spectrum is driven by how you rank the primary factors involved.
We’ve participated in a lot of these discussions with customers, and I generally try to focus the discussion around these 7 questions. They will help clarify what really matters and get you moving in the right direction. And, you may find, our new Mirantis OpenStack Express offering could be a fit for you.
Questions and choices
First, let’s lay out the key factors, and then I’ll run through them and see how your main options stack up against each other. Rather than just put them as simple questions (“Got performance?”), I want to give you a little more granularity so you can think through what will fit you best.
Control: How much control do you have over the environment and hardware? Can you ensure privacy, isolate for security and performance, and adjust the deployment to suit particular workloads? Since security is often raised during this part of the discussion, let me repeat the question: “Can you ensure privacy, isolate for security …” The concern is real, but we think you’ll find it most practical consider security within the domain of control, rather than an end-in-itself.
Deployment Time: How long before you can be up and running? How much time will you burn just sorting out, ordering, racking and provisioning the hardware? Or configuring it to work together as one cloud?
Expertise Required: Are you designing the whole environment for your specific needs, or starting from someone elses reference architecture? Can your single IT guy fresh out of college handle it all, or do you need a team of PhDs poached from the biggest cloud makers?
Performance: In a single server there are so many components impacting performance - from the memory bus to your NIC and everything in between - imagine multiplying that by hundreds of servers, along with the network plane connecting them, and the software tying it all together. If you’re going to debate performance you are looking at an endless landscape of variability. At the end of the day though, this is the one place where your budget speaks the loudest (dollars can be directly translated to performance).
Scalability: What kind of growth limitations will you face? Can your platform of choice accommodate adding capacity quickly and easily? Does a scale up or down event mean downtime for your environment, or can it be executed seamlessly? How far in the future do you need to predict your needs?
Commitment: What kind of contract or commitment will you be locked in to? From no contract “utility pricing” to the long term investment of owning all your gear - the longer you’re tied up, the greater the risk.
Cost: This may be the most important and most difficult factor to account for. You can see it as an output from your other factors, or your ultimate limiter dictating where you’ll make concessions. There are definitely some good ways to maximize your dollar while minimizing your risk as long as you keep your head up and your eyes open.
The comparison landscape I chose covers the broadest range of options, but in this space it’s also about as realistic as you’re going to get. If you need to move to an IaaS platform, it really does come down to choosing between a public cloud (like AWS or RackSpace) or a private cloud. In the private cloud world you can go with a fully managed solution, a partially managed approach (build your own and the vendor will help and host for you), or going completely off on your own by buying and building it all yourself.
Scenario 1: Public Cloud
The big players here are AWS and RackSpace, but there are other contenders with fewer bells and whistles like DigitalOcean and Linode. These represent the lowest entry barrier (you just need ‘net access and a credit card!) but also offer the least control and the greatest cost increases as you scale up.
Control: In this space, you’ll get no control over hardware or the network plane. You get no access to the underlying hardware, and no visibility into what’s beneath the covers of the cloud. There is some flexibility in configuration (for instance virtual private networks), but you’ve got no protection from noisy neighbors and no option for resource isolation.
Commitment: With most of the public cloud providers you are billed by the minute, and you’re not being held to any contract. Many will offer discounts with a commitment of some sort, but then you give up the ability to drop resources when you no longer need them.
How long to deploy: This is where they shine - being able to launch VMs in seconds from their dashboard, or from your own script using their API.
Expertise Required: In general, even the most junior sysadmin can get up to speed quickly, deploying and managing a small group of servers without having to think too carefully about it.
Performance: Generally speaking you’re going to find relatively low performance in the public cloud world. Higher performance (even exceptional performance) is available, but at significantly increased cost. Once your needs get beyond moderate it starts to make a lot of sense to explore the alternatives.
Scalability: In the world of utility pricing, you can scale up/down as needed. This is well suited to handling a highly elastic demand, but it’s important to keep an eye on what you’ve spun up - and always kill off unneeded resources.
Cost: Generally very low per-hour prices, and the price war continues to rage in this quarter. It’s fair to expect the prices to continue to edge down, though the race to the bottom will further highlight the fact that “you get what you pay for”.
Scenario 2: Hosted Private Cloud
There are many well known vendors offering options in this space, ranging from complete turn-key environments to build-to-order approaches. They will provide the hardware on short-term lease, and will charge you to manage that hardware. Additionally companies like RackSpace will work with you (obviously for a fee) to architect your environment, and provide assistance getting it up and running and keeping it healthy. Pay a premium, and you can avoid the longer terms associated with purchasing your own hardware outright and leasing your datacenter space.
Control: Control varies from high degree (renting managed hardware, deploying the cloud yourself) to minimal (hosted private cloud built and managed by vendor, adjustments limited only by budget).
Commitment: Your best case will be a 6 month agreement for a modest deployment, up to a few years for a large scale deployment. The longer your commitment here, the more the alternatives start to make sense.
How long to deploy: It’s definitely not public cloud! Your best case scenario here will be around 2 weeks, assuming your provider of choice already has the equipment on hand and you’re not expecting them to make any adjustments to suit your needs. At the outside, you’re usually looking at 6 weeks to get things up and running.
Expertise: You’ll need moderate to extreme expertise. Your average junior sysadmin is going to be way out of their depth here, but generally the vendor is happy to help out. Sometimes that assistance is baked into the overall cost, otherwise it’s certainly available if you’re willing to pay for it.
Performance: It’s entirely variable, and driven by both how much money you want to spend, and how successful your architectural planning is.
Scalability: This approach is not well suited to an elastic demand, though it’s better than the traditional “build it yourself” model. Depending on the vendor and your hardware spec, you can expect to scale up in 2 to 6 weeks. The biggest problem here is that generally there’s no “scale down” option - if you have a one year commitment, then you’re going to pay for that additional capacity whether you need it or now.
Cost: The cost is going to be highly variable, but due to the longer commitment terms it’s likely to be easier to predict annually. Just the same, successful planning will require fairly deep knowledge of the ins and outs of building a cloud coupled with a solid understanding of your needs and how they will change over time.
Scenario 3: Build your own private cloud
Now we’re in the wild west; really any option you would care to consider can become part of your cloud solution. You’ve got the greatest technical and financial risk in this scenario, but hopefully you’re headed this direction because you know exactly what you’re doing.
Control: Here you’ve got total control, and total responsibility. Since you are probably going off on your own in order to build something to your own spec, you can definitely dictate the hardware design, the network design, and how your cloud components are configured.
Commitment: You are probably buying your own hardware (or using gear you’ve picked up recently), and signing colo and carrier agreements. Between the hardware lease and those contracts, you’re in for anywhere from 3 to 5 years.
How long to deploy: Put away that stopwatch and bust out a calendar. In the best case, when you’re working from a proven reference architecture that is well suited to your intended workload, you’re 6 months from beta-testing your fancy new cloud. If you need to come up with a unique architecture (and test, adjust, test, etc) you’ll be closer to a year to 18 months.
Expertise Required: You’ll need a really sharp crew to make this work, so the expertise required is anywhere from high to extreme. There are lots of moving pieces, and the risks are tremendous, as you may be committing hundreds of thousands of dollars to your cloud pilot. Ask anyone who’s actually tried this; it’s a lot harder than it looks.
Performance: It’s entirely variable, and driven by both how much money you want to spend, and how successful your architectural planning is.
Scalability: Your scale up delay will be driven by how quickly you can get your hands on new hardware. You won’t really have any scale down options here, unless you’ve found a vendor that takes returns after some months of gentle usage.
Cost: Your costs in the build-your-own approach can be kept down if performance and reliability are of no concern, or they can (needlessly) go through the roof if you’re not making carefully planned decisions. Of all the available approaches, this is the one place where final cost is really hard to predict, as most cloud pilot programs end up missing the mark until they’ve gone through a few generations - and if you’re buying the hardware, it’s pretty hard to get out of it if you find it’s not working well for you after a few months in production.
Scenario 4: Between Public and Private Cloud, Private-Cloud-as-a-Service
Representing the best balance between the value and flexibility of public cloud and the control of a build-your-own cloud, I saved Mirantis OpenStack Express for last (because obviously best for last, right?) It’s a deploy-on-demand OpenStack cloud with utility pricing on dedicated, optimized hardware.
Let me explain why I think this is something you should consider no matter what your path forward with OpenStack and cloud. Again, let’s view it through the 7 questions.
Control: You’ve got total control over how hardware is used, and that hardware is 100% dedicated to you with no shared nodes, so no risk of a noisy neighbor impacting you. You’re also given access to underlying nodes so you can configure your environment as needed by adding security plugins, etc. You can deploy and manage multiple clouds as needed across the hardware that’s been dedicated to you, and you can re-deploy nodes to suit shifting workloads. If you find it advantageous to change some of your compute nodes to storage nodes, that’s trivially quick and easy. You can adjust your VM flavors, as well as adjusting just about any other OpenStack configuration directive.
Commitment: 1 Day - for completely dedicated hardware, use it when you need it, release it when you don’t.
How long to deploy: Anywhere from instantly to several hours, depending on the size of your cloud. The number of nodes you want are wired in to your dedicated network, and Fuel takes over from there, standing up the entire environment in under an hour.
Expertise Required: You’ll need a moderate skill level here, but your risks are mitigated by the fact that you’re in a managed environment using Fuel to deploy and manage the environment. You should know some things about OpenStack but you are by no means required to be an expert.
Performance: Starting with optimized hardware and a hardened distribution of OpenStack, you’re already starting from an excellent baseline. Beyond that, the composition of your nodes is entirely up to you, so it’s easy to adjust the deployment to suit your needs across the performance spectrum.
Scalability: This is where Mirantis OpenStack Express really stands out. By offering dedicated hardware with a minimum commitment, you’re free to scale the size of your environment up and down at nearly the same pace as if you were on a public cloud.
Cost: This is another big plus, the costs are only marginally higher than a comparable number of VMs in a public cloud, but in a shared-nothing environment. With no long term commitment and crystal clear pricing from the start, your financial risks are radically lower than any other private cloud approach.
Each of these scenarios has validity as well as a real sweet spot where that particular approach is the only obvious good choice. Today, on the small scale it's hard to beat the public cloud options, but beyond that, Mirantis OpenStack Express really does stand out. It occupies that really useful nexus where risks are minimized but your options are really not limited.
We think you'll find it to be a more effective way to do OpenStack, in a number of ways. Perhaps you use it to transition your cloud pilots and explorations to production scale with less headache than other options out there. Or, you use it as standard burst-mode capacity during the lifecycle, such as the security-vetting portion of your cloud. Or, you can use it to prove to the remaining cloud-skeptics in your organization that cloud is a reasonable, stable alternative.
The key theme is this: it’s easy to find out. all you need is a credit card, and a few bucks that you can run on your credit card. Next thing you know, the last cloud platform left standing will be “What else can we do with this?”
