 Welcome this afternoon everybody. My name is Jacob Walsik. I am a principal solution architect with the Rackspace Private Cloud team. This afternoon we are here to talk about three topics that I would like all of our customers to consider before they start talking to us about building their private cloud. It seems like a lot of times we go into these conversations and customers have some preconceived notions about how their experience running VMware is going to translate into their experience owning and operating a cloud. And they don't always think through all of the important bits that change and the mental shift that comes along with moving from a virtualized world to a cloud world. The first of these topics is all about anticipating change. More than likely when you move into the cloud world from the dedicated world things are going to be different. You might be using Microsoft cluster services in your environments. You might be using Red Hat cluster services or any other sort of traditional cluster platform that requires a shared volume for Quorum and all of that fun stuff. Those applications are not going to be able to be forklifted into most cloud environments. You're going to need some other architecture to start thinking of for providing high availability for your applications. You're going to need to look at a option for doing fault tolerance within your application itself. And you're also going to need to start thinking about doing scalability. If your developers don't have experience designing apps for the cloud and they're accustomed to a world where high availability means having two giant web servers with a load balancer in front of them, they may not be ready for a world that's going to expect them to have 16 tiny web servers spread out across a lot of hardware to help mitigate risk. When you look at your existing application catalog and you think about how do I get from where I am to a cloud, you have to sort of figure out what legacy applications I have that aren't going to be able to stick around that I'm either going to have to upgrade or replace. You have to think about applications that might be collecting user data and they expect to find some place in a file system to stick them rather than uploading them to an object store and just tracking a URL or a unique identifier. You also have to think about the, you know, what is it that my applications expect today in terms of, oh, well, I can just go swap out the hard drives for SSDs or I can stick four more nicks in that machine and bind them all together and get more throughput. You have to start thinking about how am I going to address those sorts of changes. Christian here who helped me put together this presentation kind of deemed this as the 30, 30, 30 rule. So you have to figure out what those ratios look like for your application catalog and kind of determine what sort of investment that you're going to have to make to modernize that collection of software. You also have to accept the fact that your APIs are going to change. I've been talking to a lot of folks that are already using OpenStack. They're already very familiar with Nova but maybe they haven't started using Neutron yet in their clouds. That's been a pretty popular theme of conversations that I've had this week with users. When you make the switch from Nova Network to Neutron the whole world changes. A lot of the API calls that you're accustomed to making will continue to work. Nova will pass them through to Neutron but a lot of the advanced functionality that you get from Neutron is only going to be available for the new API. Changes like that are going to happen across the board. The Elbaz platform that's part of Neutron is going to mature at some point in time and you'll be able to put more than two ports behind the same bit. The Nova API will mature over time and you'll have more and more flags that you can pass through around either aggregation zones or hypervisors specific hardware that will change the way that you think about deploying your applications in your environment. You're also at some point in time going to need to think about hybrid. Some of your platforms are going to run in public clouds but they're going to run in private cloud. Some of them might need to live in both. You might need to run primarily in your private cloud and be able to burst into a public cloud. You need to think about how you're going to do that, how you're going to handle the security, how you're going to set up connectivity between these clouds and what that's going to mean to the way that you deploy software today. The second point we want to talk about is thinking like a service provider. In a world where you're running on dedicated servers you have specialized database servers. You have specialized web servers. You have specialized proxy servers. When you move from that to virtualization you probably started standardizing on hardware but the hardware is probably optimized to run VMware not necessarily to be a KVM hypervisor host. One of the most common scenarios we run into are people that are using blades that are just booting ESX off of an SD card and then running all of their storage off of a sand. If you want to keep using VMware as your hypervisor that's great, it'll work. If you want to move to KVM and local storage for all of your VMs those blades are going to become a hindrance because you've only got two disks locally. When you start running 50 operating systems off of two spinning hard drives you're going to run into IO issues. You also want to start thinking about standardizing your tooling. You can provide much better support to your developers if they're all using the same set of tools. They can start to support each other across project teams. You can also have better automation in place and you can have better control of that automation if you're only having to worry about your enterprise chef install not your enterprise chef install and your puppet install and however you're going to manage all your recipes for all these things and the folks that are over there using Salt and all the other pieces. Thinking like a service provider also means that you're going to have to help make these users that you're enabling self-service for aware of what they're consuming. A very common thing that we hear from customers that are moving to a private cloud from a public cloud, whether it's Amazon, whether it's Rackspace, whether it's somebody else is they've got VM creep. They've got 700 VMs. They know what 300 of them are doing. They're not quite sure what those other 400 are there for. They're kind of afraid to delete them because they might have some data on them and if there's just a credit card and it's getting expensed every month, you don't necessarily have insight into where that money is going. Once you own the cloud and you can see all of those VMs and you can show to your users what they're consuming and you can look at the data from Solometer and you can go back to your user and you can say, hey, you've got these 10 VMs, you've got an enormous amount of RAM allocated to them and I have seen zero CPU utilization I need them for the last 30 days. Can we get rid of these? Do you need them? Are they gonna get spun up on the 17th and there's just some scheduled thing I don't know about? You start to gain some insight and you're able to have much more constructive conversations with a group around controlling their cost and how their needs to continue to use giant VMs is going to impact what you're either gonna have to report in your showback or in some cases what you might even be charging back to their department. The last piece is one of the most important pieces and as a private cloud provider, it is one of the most difficult to address. It is planning for integration. Your cloud is not likely going to be a standalone thing. First, it's going to have to live somewhere. Do you have a data center? Do you have more than one data center to provide a disaster recovery site? Do you have a hardware vendor that you like to work with? Do you want to continue owning a data center? Do you want to continue renting space in a data center? Do you want to use a different provider? Do you want to use a Redapt to roll in racks? What do you want to do with that gear? Where do you want it to live? How much of that existing infrastructure are you going to keep using? And also very importantly, how many of those existing processes are going to have to be rebuilt? How many of them are going to go away? You have a process now where someone requests a VM and a human being receives that request, spins the VM up, installs some software on it and then sends them a response, their trouble ticket with some credentials. Do you need to keep that process? Do you want to replicate that in a world where what you're trying to enable is agility and self-service? Some helpful resources here. Doblatory Rackspace Commercial. If you are interested in building a private cloud, we'd be more than happy to talk to you about it. We're going to re-deliver the same content through a webinar at the two weeks from now? 27th. So we are going to talk about this some more. What I would really like to do is start having some questions from you guys. How many of you own clouds today? How many of you are thinking about building clouds? How many of you have started making these decisions and what kind of factors have you found that have really sort of helped you down that path? Please. Hey, I'm Trevor from RMS. Great talk. We're going through this right now. We've been out of cloud for the last couple of years and one of the biggest challenges that I think we've seen is changing people's mindsets, everything on your slides. We have a group of people that have done it and then they're the new people and then the other people that haven't done it. And I think just the biggest thing is the mindsets about the servers, big VMs, thinking about re-architecting your application as far as being monolithic versus clustered and it can expand and all that sort of thing. So yeah, that's great. Thank you. One of the things you mentioned about large VMs, interesting conversation that we have on a pretty regular basis is how do you determine your instance sizes? And it's a pretty basic, you know, mathematic formula. Your whole hypervisor is square shaped and you want to find a bunch of square shaped VMs that fit inside of it. So rather than giving people the ability to create rectangle shaped or octagon shaped, you define flavors for them that are square shaped so that you can get the most utilization. But that does require re-education. That does require having people aware of what the cloud can do for them and what it can't. I gave a talk on security groups yesterday and somebody asked me, how do I get my customers to stop using IP tables rules inside their VMs and start using security groups? And if they have root access to their VMs, you can't. You know, they can go in there and they can do whatever they want. But you have to be ready to, you know, as part of anticipating change, it's going to require some retraining. Hi, I'm Sridhar from ThoughtWorks. And I've had to be administrative of quite a few private cloud setups at ThoughtWorks. And honestly, they were not clouds. You know, they were just a lot of VMs that we used to spin up and run for our projects. One of the practices that I started to adopt is make sure we have configuration management and then delete some VMs and recreate them and make sure the app still runs. That way I work with the devs so that, you know, we move away from snowflake servers or snowflakes, VMs being their works of art. You cannot recreate them again. And making sure that devs understand that if it ran there today, it better run the next time I spin up a new VM. And one of the things that we moved towards was I did something a little bit radical wherein on one Saturday, I said that non-words every Saturday we're going to delete all these 500 VMs and start spinning them up on demand every Monday. That way, even if you have a build with customized settings for that specific, you know, dev environment or whatever, it does not persist beyond a week. And it better be fixed by the next week. Now, because I'm a dev, I know how to work with devs and get these things sorted out. But we found that helped us move away from a snowflake servers towards what we call Phoenix servers. That is a very aggressive approach and it's a somewhat admirable approach as well. For those of you who aren't aware, Netflix, Adrienne Cockruff started a project a while back called Chaos Monkey that does something similar and the folks at PayPal ported it over to project that I can't remember the name of to have it work with OpenStack. Because Chaos Monkey was designed to run against AWS and it was the exact same sort of idea. Random VMs in your environment are just going to get killed off and if you've designed your application properly and it is truly cloud ready and your persistent data is stored or persistent data should be and your VMs are deployed from configuration management, you should be completely tolerant to that. One question. How much of an operational change do you see companies need to do to build a private cloud? Because when I talk to companies that are doing it, they seem to really moved away from that silo mold. Is that something you see as well? It's a pretty substantial operational change. The degree to which it will be impactful largely depends on how the organization runs today. In a group that is, has IT be more siloed? I mean, we have any number of marketing departments from companies that are customers of Rackspace's traditional hosting platform because we can stand up servers, we can stand up in a full blown environment with storage and network devices and whatever in less than a month versus them having to go through a 10 month process. So even with dedicated gear where we feel like that's a slow process we still move faster than their internal procurement program. So some of it is that, some of it is, okay, so I'm going to be able to take that person who received that trouble ticket and laid down the Windows image or copied the master VM for a Windows VM and then went in and installed and made sure all my security software and all that stuff is in place. I'm going to be able to take that person and I'm going to be able to have them go and do something more valuable. I'm going to have them evaluating the next generation desktop platform. I'm going to have them building automation for my application deployments. I'm going to have them really shoring up my monitoring so that I have all this great telemetry about what's going on inside of my environment. And the customers that we have that look at a move to cloud as an opportunity to get more valuable time out of their staff. They're the ones who have the most success with it and they're generally the ones that their staff is the most excited about adopting it because they don't look at it as, oh, well, you're going to do this automation thing and then my job is going to go away. They look at it as, oh, we're going to do this cloud thing and now my job is going to be more interesting. I'm not going to be doing repetitive tasks anymore. Thank you. I'm an engineer. My thought process is a little different. So I'm going to ask two questions. One, the word cloud is used and abused, you know? VM shop is not what you're calling a cloud. So one, if you describe what, when you say cloud, what you mean more IaaS or D-Bass. I'm largely referring to the infrastructure as a service platform that is sort of the core for like any of the public clouds that you're familiar with, the Rackspace cloud, Amazon, Linode, any of those. And I'm also referring to private clouds based on OpenStack, whether it's our platform, Piston, Morantis, you know, any of the others that is the, you know, it's the infrastructure as a service piece. It has an authentication piece. They normally have some block or object storage bits, but I am referring to, you know, API enabled infrastructure as a service. Okay, thank you. And then the second is, you know, how do you, when a customer wants to choose or the company wants to choose why OpenStack over AWS or over, you know, whatever else is out there, what do you see as advantages and disadvantages of both? So the why AWS versus OpenStack is largely a, more often than not, comes down to a cost play. You know, Amazon has committed themselves to a price war where the race or the race to zero for the cost of compute. That's they cut their prices twice a year and it's a regular sort of cadence. And if all you care about is I want the cheapest thing, then Amazon or Google is a clear option. For most general compute scenarios, a public cloud has a fixed cost. I pay 30 cents an hour for a VM of this size. And if it runs for, you know, five minutes or if it runs for 50 days, I paid 30 cents an hour for that VM. At some point I might get a discount. I might, you know, get 15, 20, even 50% off. But when I have enough of those VMs, it's going to be more expensive for me to keep paying that flat rate per hour for every single VM than it is for me to go out and build my own cloud. So you either have to have a provider who has a flexible enough cost model to support you scaling in that way, or you have to accept that, okay, I'm at the point where I have 2,000 VMs that are running all the time and it's going to be cost effective for me to go in out and build my own cloud because as I build that cloud and my footprint's larger, the sunk cost of the firewall or the load balancer, the storage appliance starts to average itself out across all of those VMs. The choice of which platform to use, should I use OpenStack, should I use CloudStack, should I use Eucalyptus, could be purely philosophical or it could come down to finding a service provider that you really enjoy working with because they push all the right buttons in terms of what you're looking for from services and that service provider happens to use PlatformX. So PlatformX becomes an obvious choice because the functional difference for basic compute is kind of minimal and what's more important when you go to build your own cloud is largely who is going to run it, how are they going to run it and where is it going to live, more so than it has to be OpenStack because OpenStack is open source and that's better than something else. Yeah, if you want to leverage existing infrastructure, some of our customers, they seem to be, we don't find many customers that are in the middle on this opinion, they either have existing data centers and they want to continue using them and maybe they have some sort of regulatory reason that they have to stay in their own data center or they want out of the data center business, they've been running data centers for a long time, they're sick of doing it, they never want to have to buy another server again. So that can definitely influence your decision as well. A minute or two left, right? Yes. Okay, I'm Daniel from Omeo University. We're looking into cloud services for researchers who need cloud infrastructure, IAS, but I wanted to ask you all the different customers you're working with, what are people using it for? He talked a little bit about strategies to handle VMCRETE, but that's going to vary wildly depending on what the users need and what they want. Some people need a little tough love, others will hate you for it, so. So we have research organizations where they are using it for researchers to either run simulations, store data, whatever the case may be there. We have a lot of test dev shops, so they spin up infrastructure service clouds, and what they're looking to do is they're kind of fighting the shadow IT battle. They know that their developers have gone out and thrown down a credit card at Amazon, and that unless they can offer a service that at least smells a little bit like Amazon, they can't get that computing back in-house, and some of those customers, especially the ones that are in heavily regulated industries, have concerns about a developer playing fast and loose with company data. So they're doing the development there, they're doing their continuous integration testing there. It's not dissimilar from the way that the foundation runs all the, whatever the CI test for OpenStack itself, and we also have customers that are running production applications, mostly like scalable web apps, and they're starting to kind of explore the true flexibility of hybrid where they have eight or 10 applications that are running in a cloud, and if one of them needs to scale beyond a certain level, being able to leverage some sort of private network connectivity to be able to start spinning up resources in our public cloud. Anybody else? Okay. Yes. I'd like to share some lessons learned about coaxing the IT teams to say, yeah, it looks, our jobs are not on edge. How do you think? So, I generally find two different models for how a large enterprise starts the cloud journey. It generally involves a new leader coming in, so you've got a new CIO, and they got hired because they said cloud enough times in their interview, and they lay down the law one of two ways. They say, all right, June 1st, everything that we deploy after June 1st has to be in a cloud, or they look at their catalog and they look at the natural sort of life cycle. The, you know, most enterprises have like a three to seven year life cycle on a given application environment based on the hardware and the software and all that's fun stuff, and they say, okay, anytime we do an upgrade from now on, the new environment has to be into the cloud. And so, when we start having the conversation at that level, sometimes we are, you know, we become part of the sales pitch to the rest of the organization. And the organizations that do have a lot of the siloed IT, I spend a lot of my day making sure that backup tapes are in the right place, and I'm right clicking on VMs, and I'm replicating them, and I'm making sure they come online, and I'm sending somebody credentials. The shops that have that sort of process are generally far more open to the idea. They, you know, there was at least one occasion where I saw a man genuinely like excited to come back to work tomorrow. He's like, wow, so we're gonna get this cloud thing, and I can finally finish this monitoring project that I've been working on forever so that the marketing people will stop bugging me when the website gets slow. I'll be able to know before they know. You know, so it's, it really is. I mean, there are gonna be places where you're gonna have the, you know, you have a model where they still have computer operators, and they've been a computer operator for 20 years, and they follow that manual, and if you ask them to work outside of that manual, they have a hard time with it, but there's not many of those shops around anymore. Do you have a recommended path for a smaller, medium-sized IT company that's just getting into some type of cloud setup to import their virtual machines? Do you have, say, you keep the, you give your dev team, you know, do you one, give your dev team, say this is this new app that's gonna utilize all these aspects of the cloud, and we're gonna do that first, continuously integrate it, or do you pull in, you know, one-off servers and convert them over and make them their new base images for everything else? Do you have a recommendation? Pulling in the one-off servers is generally a bad idea. You're kind of violating sort of the tenants of why it is that you're adopting the cloud. You may find, thinking back to the 30, 30, 30, you may find that some of those one-off servers aren't going to come into the cloud. You may find that you have a Oracle Rack Cluster that's sitting there in the next rack over, cabled into the same VLANs that is going to continue to be a physical Oracle Rack Cluster because maybe you're bound to Spark, maybe you're bound to Oracle, like whatever the case may be, that's not gonna be part of the cloud. You almost always have some sort of application transformation that comes along with it. The three-tier web application model that we've been, you know, that's idea that we've all been familiar with for 10 years now comes over very easily. You know, the proxy layer, the application layer, the web server layer, like all that stuff comes over just fine. Sometimes the data tier can be a bit dicey, but you know, those pieces are already designed to be loosely coupled and they're horizontally scalable. And so you can run small blocks and you can have lots of small blocks. You can spread them out across a lot of hardware and you know, you generally want to stick with a public cloud if possible when you're in that starting mode because a public cloud gives you access to a lot more hardware than you can afford to put in a private cloud. There is a point at which you need so much, you need a certain number of hypervisors before a private cloud becomes something that you want to use for a production environment. If you only have two hypervisors and one of those hypervisors fails, you have lost half of your capacity, potentially half of your VMs. If you have 20 hypervisors and one of those hypervisors fails, you've lost 5% of your capacity. And the model that this man described earlier of randomly killing off some of those VMs or maybe even randomly pulling the network cable out of a hypervisor? If you only got two hypervisors, that's gonna be a far more impactful process than if you've got 10 or 20. It sounded like a lot of your discussion. It was kind of an implicit assumption that moving to a cloud is good for, just your general assumption with what you're talking about. But another common thing that I keep hearing at this particular summit is that many parts of OpenStack in particular aren't quite up to the 5.9s level. Have you had experience with moving applications that need the 5.9s and are strongly state dependent to cloud type systems? If you have an application that is heavily state dependent and relies on, as I mentioned earlier, like some of the traditional models for doing clustering, where I've got two machines, they have a shared volume, they've got a heartbeat cable, and if this one dies, this one grabs that volume and takes over, that's not a model that translates well into most infrastructure as a service cloud platforms. And that is not an application that is ready to be moved to a cloud in its native state. As a general rule, when a customer approaches us about building a cloud, they have already decided that there is some benefit to them of building the cloud. I will not say that building clouds is universally good, that you should cram it down everyone's throat. You definitely wanna be sure that it's an organization that's at a point that they're ready for it. We've built clouds for customers that their CIO thought it was a great idea, and we've never gotten a single ticket from this customer what's going on, and we call back over there and we talk to somebody, either an operator, a director, a sysad, whatever, and they may not even know they had it. They forgot about it, they never started using it. So, I mean, forcing cloud upon people is not very helpful, and moving to cloud is something that you should do with a purpose. You're looking to gain agility. You're looking to enable self-service for some portion of your business. You're looking at being able to move to a pure commodity hardware model, and you're okay with the software cost, the software development cost is gonna go along with it. There are a number of things about adopting cloud that are very beneficial to enterprises, but if someone's not ready to adopt, then you don't wanna force it upon them. Well, if no one else has any questions, thank you all for coming out this afternoon. Oh, we got one more. Just on your point about the question that the gentleman over there asked, about some applications not being ready, and this is my opinion, by the way, right? So, being a VMware shop, and we're looking at Alpastak, some of those applications that can't be moved can actually be moved, right, and you can do it with VMware, and I'm not of you and myself, but I work for Armist as well. But bearing in mind that when you're looking to doing this, this is the lessons we've learned over time, and our application isn't really the most cloud-friendly application I've ever come across. But I went to an Amazon site a few years ago, and Amazon presented it in quite a good way, that they said, when you wanna move to the cloud, there's three sort of phases, and one of them is that you literally get a forklift truck, pick up your product, and just dump it in the cloud, and you're not doing anything more than saving operational costs. But your application isn't cloud-friendly, right? So, for example, this scenario that the gentleman over there gave, like we have SQL clusters, for example, and SQL clusters aren't great, they wouldn't work really well with KVM and whatnot, but on VMware, it works great, and as you've probably seen in some of the summit talks that people have done, you can put Alpastak on top of VMware and still do what you were doing before, and continue using the state hardware, so it doesn't mean you can't move, this is a phase of moving. And then the next phase is, okay, now can we look at changing that? And the last phase is, okay, we're gonna actually embrace cloud technologies like Redis or Mongo or whatever it might be that help you move to that phase, so I think saying that most use cases, I mean, I have asked personally, again, my limited experience, I still have to come across something that you couldn't move, and so I just want to state that. It's definitely possible to use vSphere as your hypervisor and still get all the benefits you get out of VMware today, and be able to adopt OpenStack, essentially it's an alternate control plane for your VMware environment. That is a very, very feasible model. VMware is happy to help you down that path. It's really just comes down to, is it worth the investment of putting OpenStack on top of it and still paying all of your vSphere licenses? Is that the model that you want to go to? If you listen to any of the NOVA sessions about alternate hypervisors, if you talk about any of the storage sessions about using a NetApp or an EMC, these commercial, expensive, supposedly storage appliances, the reason this whole ecosystem of hypervisors and different server families and different storage platforms exist is because they're all right for somebody. Based on what my point is that if you want to move to the cloud, you can do it, but it's just the stages you might have to use VMware for the next six months and then leave VMware and then start going. But you can't just decide, okay, I'm gonna use OpenStack today or CloudStack or wherever it might be, AWS. But it's just, they are processes. And again, the point was just about, look at saying that Oracle is the only thing I can think of, right? Because Oracle is really, yes, and Oracle people are here. But it's very painful with the Oracle Rack licenses having to be on physical hardware. But that's the only thing I can think of. But generally, otherwise you just, you can do these tricks around, I'll use VMware for six months or a year to get everyone on board and then slowly coach them into saying, well, this doesn't really work if you wanna start doing the Amazon-like stuff and then move them onto different technology, et cetera, et cetera. Yeah, that's very true. If that's a path that you wanna go down, it's definitely one that can be followed. All right. Well, thanks everybody for coming out this afternoon.