I get this question about cloud a lot. Sometimes in those exact words, sometimes in a longer and more drawn out fashion. The answer?
Yes. It just depends on your definition of cloud.
Honest, it really does depend on what it is you’re trying to accomplish. I can’t just tell you to “move west, young man!” There many different things to consider, some of them more obvious, some of them less so. Here are some of those variables to consider:
- How do you define cloud? – Ask 10 different Italian grandmothers how to make marinara and you’re likely to get 10 different recipes. Yes, they’ll all involve tomatoes, a pot, a spoon, and a stove, but those might be the only consistent elements. Defining cloud for some folks is similar. Asking customers and colleagues to define cloud, I sometimes get one-word answers like “AWS” or “OpenStack”, but they may or may not understand the implications (see “scale up vs scale out” below”) . Or sometimes I hear more thought out answers like “the ability to consume compute, network, and storage resources on demand regardless of their physical location without losing insight or control.” Sometimes the answers are somewhere in between. Those types of answers really leave room for things that some of us wouldn’t traditionally think about when we think “cloud”. What about hybrid cloud? Let me get back to you on that.
- Your reason to go to the cloud – Reasons to go to the cloud tend to be fairly consistent though: I want to consume resources faster; I want to have a more consistent experience as a user; I want a self-service portal; I want more automation/orchestration; I want faster time to market; I want more control over IT spend, etc. Or even, “my boss told me we have to go to the cloud and none of us actually know what that means, including him.” I hear that more than you realize, and it’s actually ok.
- Application architecture – Your application architecture is also critical, because if it’s a “traditional scale-up, monolithic, all binaries and libraries in the same VM”, then that’s not going to AWS or OpenStack anytime soon. (See below, I promise I will tie this all together..) Not all applications are bound for AWS or OpenStack. HOWEVER, that doesn’t mean that they can’t benefit from automation, orchestration, or other major components of “Infrastructure as a Service”.
- Development methodology – Your development methodology is also big component to consider. If you work in waterfall, AWS and/or OpenStack will likely be painful for you. They are not just platforms, but part of a larger tool chain. On the other hand, if you are or are going to be “agile”, then that larger tool chain will be a more natural fit. And no, “fast waterfall” or “waterfall with sprints” does not actually qualify as “agile”. Please try again. 😉
- Size of IT team (infrastructure and developers) – The size of your overall IT team is the last big component to consider (aside from budget, again, I don’t cover budget here). AWS and OpenStack require deep coverage in your IT team. OpenStack means having deep Linux knowledge and deep development knowledge. AWS means more of the latter. If you’ve got it covered, then great. But if it’s you and a couple of guys, then look at what I consider “Cloud Light” (see below). Again, below..
- (I don’t cover budget) – But it’s definitely to be considered.
Those of you that don’t know me professionally, I spent time as a “Cloud Solutions Architect”, which is an expense way of saying I did pre-sales for a cloud and emerging technology portfolio. I only mention this so that you understand I’m not talking about this as a spectator. As we get further into this post, I’m going to introduce something I refer to as “Cloud Light”. It’s nothing new or Earth-shattering, just trying to NOT reinvent the wheel.
Scale Up vs Scale Out (Borrowed from one of my earlier posts)
OpenStack (and AWS for that matter) is NOT a replacement for vSphere or RHEV or Hyper-V. Those are “scale up” technologies.. OpenStack (and AWS) is a “scale out” technology. You run monolithic applications (like a full LAMP stack for example) on traditional virtualization. And when you need MOAR POWR, you add more vCPU and/or more vRAM to the VM. In OpenStack, when you need MOAR POWR, you add more instances and spread the load. This of course means that your applications have to be written in a manner that can take advantage of the architecture.
For example, in a basic LAMP stack application, you likely have your Apache, PHP, and MariaDB all running on the same VM. When things get overloaded, you may add additional CPUs and/or RAM to the VM. That is “scaling up”. That is also a “stateful” application. Because that application is monolithic and depends on scaling up for additional performance, it gains absolutely nothing by running in AWS or OpenStack.
On the other hand, if that application were broken up into it’s discrete components and/or microservices, it could take full advantage of OpenStack (or AWS). (And yes, I really that would require a complete rewrite, this is simply an example.) Apologies for the over-generalization, but I’m going to use my same LAMP stack application. Instead of 1 single application that houses Apache, PHP, and MariaDB, we have discrete web servers, middleware, and database components. And instead of 1 each component, we have many. Maybe tens, twenties, or hundreds of each component. All spread intelligently across OpenStack (or AWS) compute nodes. And when things get really busy, you add more web servers or whichever components need MOAR POWR. That’s “scaling out”.
It also means that hypervisors can fail, be updated, or rolled out without disrupting service. Why? Because redundancy has been removed from the physical infrastructure, removed from the VM, and moved to the application. Quite powerful indeed.
But Captain, you said something about “hybrid cloud”. Awesome, you were in fact paying attention. Really, this is just making use of resources that are available to you, regardless of their location – public, private, owned, or hosted. However, it also means that you need a unified way of managing it…. (the plot thickens..)
The truth is, I don’t see anyone going 100% public cloud or staying 100% traditional virtualization. I also don’t see very many folks going 100% public or private. Sure, there are outliers. But by and large, most customers are hybrid, or will be, whether they realize or not. Some apps just won’t get migrated to public cloud. Some companies just won’t go completely agile. This just means that they will need a Cloud Management Platform (CMP). A good CMP will help bridge the gap between disparate platforms, hypervisors, and even locations. Typically they also provide automation, orchestration, reporting, and integrate with third parties. Essentially, a good CMP will manage your hybrid cloud environment.
What if you fall into the category of needing automation, but don’t want public cloud, and don’t have a big IT team? You need to provide self-service and need “private cloud”, but can’t justify OpenStack? You need flexibility and insight, but need to keep things on premise. Simple. Put a solid Cloud Management Platform (CMP) in front of your virtualization platform. You still get your “Infrastructure as a Service”, but your small team isn’t overwhelmed, you still get reporting, automation, orchestration, integration, etc. I have a couple of examples, including my favorite Virt+CMP tandem, and I’ll likely start posting demos over the next few weeks/months. Call me out on it if you don’t see it soon.
Wrap It Up
This is a huge topic and conversation that could span months with consultants, sales teams, and customers. And it often does take months; I don’t want to diminish or minimize the discussion(s). I just wanted to give a little high level view of things for anyone looking for some general answers. Plus I wanted to give a little tease for what’s coming in the near future for the blog (Cloud Light..) Going AWS and OpenStack is the right way for some, but not all. I’m not telling people not to go that route, I’m just suggesting that use case is everything. When I talk about “cloud” for the foreseeable future, it will be in the context of RHEV + other tools that build on RHEV.
Hope this helps,