 Good. So good afternoon. Welcome to the OpenStack Summit and my presentation on migrating from Amazon AWS to OpenStack. We're officially more than half the way through the summit and the day, so for those suffering from lunchtime food coma. Congratulations. Wednesday's almost wrapped up. My name is Steve Curry. I'm the founder and president of MetaCloud. I departed Yahoo in 2007. I was there for eight years of service. I was the first storage operations employee at Yahoo and went on to build the team globally. I spent about half that time in the US and half of the time in Seoul, Korea. I spent a lot of time in the APAC region because there was a tremendous amount of growth at that time for Yahoo. After Yahoo, I began a quest to make my dream come true and figure out exactly what I was going to do next, something else. I wasn't for sure, but I spent 2007 through 2011 researching and understanding the underlying problems within the enterprise. And what I found was there was a massive inefficiency within infrastructure and it was a massive opportunity as well. So together with Sean Lynch, we founded MetaCloud in August of 2011. Companies based in Pasadena, California, we come from a very big operations DNA. The majority of the company comes from Ticketmaster and or Yahoo operations team. We're backed by some fantastic VC firms, Storm Ventures and Ame Cloud Ventures, which is AKA Jerry Ying, one of the founders of Yahoo. If you want to find out more, you can visit our website at metacloud.com. And yes, we are absolutely hiring. What I hope to deliver today is an overview and case studies on migrating from Amazon AWS to OpenStack. I'm not here to talk negatively about Amazon or the public cloud in general. I created this presentation last Friday at about 6 p.m. while on a flight back to LA. However, those who know me know that about 50% of this presentation was written between 5 a.m. and 9 a.m. this morning. If you caught the outage this morning that was affecting those who store presentations in Google Docs, this presentation almost became a presentation on how not to store presentations in the cloud. I was sweating it, but fortunately things got resolved and back to the topic at hand. An interesting bit about public clouds and a bit of a tangent. When you have to run a profitable business based on infrastructure as a service, you become extremely efficient. Most enterprise private clouds are not efficient. Matter of fact, they are very inefficient and typically a black hole of capital. OpenStack does a lot to address these inefficiencies. It's not just about virtualization. Virtualization is like a hotel built for one family. One family that doesn't need a hotel often and is not that big. If your family is that big, I'm sorry to hear that. This virtualization is not a driver of efficiency like most people think that it is. The driver of efficiency really is a combination of technologies. That is virtualization, orchestration and multi-tenancy. This combination is like a hotel built for everyone. Think the public cloud or a company with lots and lots of business units. It's a very efficient use of that theoretical hotel. Of course it's a bit more than that and we'll get into that a little bit later. That's a little bit strange. Amazon AWS. It's a great place for startups to begin. There's no cloud operations or cloud engineering really required. You often hear about companies such as Netflix refer to their no ops model. There's also a large catalog of supporting services. There's a large ecosystem of third party applications. For example, right scale. It's great for companies with very spiky traffic patterns or seasonal traffic as well. Some of the cons, it's expensive at scale. It's very expensive at scale and we'll get into that as well. There's zero availability guarantees. Typically there's no SLAs and control and support are also major issues. We all understand what the public cloud is obviously. What are some of the mysterious parts of the public cloud or Amazon? The Amazon compute unit. We often hear companies asking about it and we often find ourselves talking about it. What a compute unit is. From the horse's mouth, it's the equivalent of a 1 to 1.2 gigahertz optron. It's a bit of a fuzzy description about what you get, but performance is variable, meaning that it's really hard to accurately baseline performance anyways. Once customers understand what a compute unit is kind of, the next question is how many compute units are in a server? Well, typically in today's server, and I'll talk about the server a little bit as well, we see between 70 and 100 Amazon equivalent compute units per server. That's a server based on about $5,400 and I'll go into a slide in a little bit talking about how many CPUs that is, how much memory, etc. Of course, this varies depending on the type of hardware that you do select ultimately. Amazon EC2 pricing. The VM price goes down and Amazon margins go up. So yes, you're reading that correctly. It sounds a little bit weird, but I'll definitely explain it. Server CPU performance increases about 50% every two years. So what that means is that same example of 70 to 100 compute units becomes in two years 100 to 150 compute units. And the simple fact is that if you're serving more compute units per server, that equates to higher margins for Amazon. Compute unit utilization goes up over time. Applications become more complex over time. The VMs that companies deploy get larger over time. So congratulations to Amazon. That's a killer business model. So this slide speaks for itself, but this is the slide where we'll talk about. I can make this a little bit easier for me to see. The math that went into when you're talking about compute units and the cost between public and private pricing of clouds. So if you look at 40 servers, let's call it a rack of servers, 1U servers. And again, $5,400 per server that equates to about $230,000. And that's two sockets of 2.5 gigahertz Intel Xeon CPUs. That's about 256 gigabytes of RAM. I'm not sure we're going on with the math in my head right now. That's 70 Amazon compute units per server. I used the smaller end of the scale because I wanted to be conservative as well. And that's amortized over three years. And that's versus the Amazon equivalent where I took into account reserve pricing. You would spend $600,000 for reserving those instances. That would be about $416,000 per year for those instances just at one year. And over that three-year term, because we're comparing it to the hardware that we purchased for a private cloud, that's $1.2 million roughly for the three years. Now, of course, in the private cloud pricing model up here, I don't take into account the cost of humans. But you can do the math on that. You know about what it costs for a human to manage or multiple humans to manage this infrastructure. But as you can see, it's clear that if you run private clouds efficiently, the cost savings is really there for you. So this leads us to the typical triggers for leaving Amazon, the monthly spend, concerns around security, concerns around performance, and concerns around location and even vendor lock-in. So successful startups rise to the top, and rapid growth is a growing pain for every startup. And they need to address that, obviously. Demand for compute increases, features increase, infrastructure requirements grow. We see startups get to this $100,000 per month mark. And across the board, we see this number trigger search for alternatives, typically pulling it in-house, building a private cloud, and utilizing that solution to drive down cost. Why $100,000? I'm not really sure, but I suspect that it triggers what we call the call from the CFO. Kind of wanting to know, well, we're spending at least a million dollars a year now on this solution. And it's getting expensive, and we've got massive growth. This is only going to continue to get more expensive and could become a problem. So we're often asked, how does a private cloud compare to what I have now in the public cloud? Well, that's a great question. Performance examples and performance tests on your public cloud. So I guess what I mean is, customers will say, well, how does my private cloud perform compared to a private cloud? It's hard to find out the answer, because if you look at loads that are set on a public cloud, they can really vary, because your neighbors could be doing a lot of IO intensive applications. And we'll see when we run tests in Amazon or in the public cloud, it varies a lot from day to day, test to test, hour to hour, minute to minute. And vendor lock-in. Someone else perfected it on Amazon, and a lot of others are leveraging it. Considerations before ejecting or leaving a public cloud. So there's plenty of tools to help you migrate. Depending on your hypervisor, Amazon AMIs will run as they are. For example, KVM hypervisor. There are lots of things to consider. What tools you're using to orchestrate your Amazon infrastructure? How much data you're moving? Using Amazon APIs directly or third-party tools like RightScale. The richer API interface is, of course, OpenStack. And this should be discussed with your team before you move. You need to understand the implications of moving applications that you're used to using in Amazon and what happens when you move it to OpenStack. OpenStack provides a lot of services within their catalog of services that they support for their customers. For example, Route 53, Elastic Load Balancer, RDS. These should be addressed and discussed with your team. And for OpenStack, a lot of these aren't covered yet, or there's still an incubator status within the OpenStack project. So planning the hardware layer. So data center. How many and where? Foundational infrastructure like network gear, storage gear, and compute. This is often a religious or a religion, although most customers do ask us for help. What I mean is a lot of people will swear only by Dell or HP or Cisco. And how does this map to any current corporate requirements? So for example, corporate authentication. Planning for the human layer. You're going to need a cloud engineering team. And it's probably something that you're not used to if you were an Amazon customer. Especially if you were a startup that started very small and you were leveraging the ease of use and the agility of a public cloud. You didn't need to have an engineering team. You didn't need to have an operations team. But now you do. You do need those teams. And what this means is maintaining OpenStack code base. Backporting upstream patches for and security updates. Integrating with corporate services. Again, Active Directory, for example, billing and security. And integrating with other open source technologies such as Ceph, CoreSync, Pacemaker and configuration management systems. OpenStack is complicated. It's definitely production ready. It's definitely enterprise ready, but it's very, very complicated. So, you know, we come from a big ops DNA. The team really understands global infrastructure at a very extreme efficiency. MetaCloud has a product called Private Cloud as a service. And we're really that cloud operations team for our customers. So, managing infrastructure at scale is hard to do. Most enterprise IT teams struggle to keep up and stay relevant with what their customers need and the growth of their company. MetaCloud layers are software on your hardware in your data center. We proactively support that cloud on our customers behalf. That means when we detect issues, we see ECC memory issues. We see smart hard drive errors. We'll proactively, without you calling us, migrate those VMs off that suspected bare metal and quiesce that bare metal. Open up a ticket with your team to make sure that bare metal gets addressed, gets fixed when it's healthy again. We'll tag it back into the system and we'll bring VMs back on top of it. We have this support model where it's a lot like... So, you simply consume and we provide this instant level of support. We're streaming back health and performance data on your cloud. And typically when our customers call, we know about the issue and we let you know that we're addressing it. And here's an ETA to resolution. It's a much better solution than calling support and saying, I've got a problem and I need to articulate this issue to support. That could take hours. Supports got to articulate the solution back to you. That could take hours. And if you're responsible for a production cloud, you're feeling a lot of heat. You're in trouble. You're stressed out. That's a bad day. We deliver production ready open stack and we deliver production ready support. So, I'm going to walk through a couple of case studies. This is the first one. This is a streaming media company. It's a formally an Amazon marquee client. High growth startup. Over 200 million unique viewers. Delivers over 1 billion video streams per month. The challenge was explosive growth and rapidly scaling business. As a public cloud customer, this often results in explosive growth in your monthly bill as well. I'm not saying I'm just saying it is. Customer SLAs demand predictable performance, reliability. And support response. Rapid support response. And the delivery model requires a presence outside of current Amazon footprint. So, what that means is this company needed to be in locations where Amazon didn't have a footprint. And that was something that they needed to do software. And that's something that we can help them with. So, MetaCloud delivers open stack, SEF and our IP to provide an extremely stable, reliable and cost effective private cloud solution for this customer. A quote from them. As wonderful as the public cloud is when it comes to agility and ease of use. There was a point where the cost simply became staggering if you start to scale. MetaCloud's open stack based private cloud is going to allow us to continue to enjoy the public cloud. Benefits that we become used to and we expect while delivering significant improved economics and predictable performance. Case study number two. It's a major media and entertainment company. So, massive companies, centralized IT department, like a lot of enterprises have, supporting multiple business units. You know, today most enterprise IT teams feel measured against Amazon. Amazon provides very agile services. You can go there, you can click a mouse, you can get infrastructure rapidly. Now, if any of you have worked for an enterprise in the past or do today, you know that that can take weeks or months in some cases to get infrastructure provision for you. I've been there before, I know I've made phone calls and it takes a long time longer than I expect or need to get that infrastructure for me to use. So, what we do is we provide that agility to enterprise IT teams. We, via open stack and our stack of IP, provide agility on top of an enterprise's hardware inside of their data center. We'll brand it as their own. We'll allow them to get all the kudos internally from their team. It creates a great relationship between us and our customer and they love it. If you look at the enterprise server market, it's a $55 billion market. It's growing year over year. It gets bigger every year. But the interesting thing is, is that across the board, server utilization is between 10 to 15% utilized. It's really low. And virtualization, again, as I mentioned earlier, never really solved that problem. So, every enterprise is looking to drive up efficiency of existing hardware. And existing hardware is something that we have no trouble laying our software on top of. We don't require prescribed hardware. We'll help enterprises solve the problems they have with their existing hardware. And that's typically how we start an engagement. And then when we find success with that customer and we grow that environment when they want to go greenfield, they typically come back to us and ask for advice on architecting that next solution. So, the solution, again, was driving up efficiency on existing hardware. Let's see. Major efficiency is not only on the hardware layer, it's also on the human layer. So, what this means is, while our customers saw an 80% increase in hardware efficiency, what they didn't expect was that they got a 60% increase in the IT team efficiency thanks to things like self-service provisioning. A lot of current solutions don't really have an answer to that. And when you enable an end user to come and provision hardware for themselves, it makes them happier and it makes you happier too because you spend more time addressing things that are more valuable to the company and the customer gets rapid access to virtualized infrastructure. It's a win-win. Another interesting fact that we see across the board almost entirely is that CIOs, the role of the CIO seems to be changing. CIOs are becoming more and more like brokers of technology. They're looking for smaller, very innovative companies to come help them be successful, make their teams successful. They're more open to the idea of working with smaller companies to bring success to their organization. And it's less about just building an in-house or, oh, we'll do it on our own, we're a massive corporation. So, they know that they can leverage smaller companies for this agility. I think that's a great thing for all of us. Most of you are in the same band or the same camp as Metacloud. We're smaller companies, we're rapidly growing, but we can provide very agile solutions to very large companies. So, I'm getting close to the end of my presentation here and I just briefly, the future of the public and private cloud. I think that both will always exist. The lines will definitely blur over time of what public and private cloud is. The difference will be more about features, on-premise versus off-premise, seasonal versus fixed rate workloads, etc. The public cloud market is big, the private cloud market is massive. So, there's a lot of opportunity for all of us out there and I wish you all success. Thank you. I'm happy to take questions if anyone has any. You, sir, in the back. So, I really think that's up to the customer. It's what appetite they have to get out of the public cloud. How painful is it? How big is their bill getting? What is their prediction for growth of that company in the next 12 or 24 months? We will definitely help them move that data. We've helped customers migrate VMs. We have this very white glove support model. So, we will do a lot to work with our customers to help them understand how to make these things happen. But I would say that's definitely up to the customer. I don't think that we would provide advice on their appetite to move a certain amount of data. I think it really has to do with their underlying business drivers. So, it's really hard to give specifics on customers because they typically don't want us to talk about that stuff. But it was definitely lots and lots and lots of terabytes. Probably petabytes. So, that's a great question, by the way. You're welcome. Yesterday at the demo theater, myself and Todd Cranston, who also works at Metaclod, we were up on stage and we were really reaching it. We were asking the community in general, we need to do a better job of creating materials for those end users to consume to help them be successful when they're leveraging OpenStack. I think that's a gap within OpenStack and we've really got to address it. And that's something that Metaclod wants to spend time this year, but it's not going to be just us because we don't have the resources. But I think as we leverage the community together as a whole, we can help fill those gaps. Now, there's specific things that we do at Metaclod. Maybe our UI is a little bit different. We've added some features to the UI and we'll have to provide that documentation because it's a SKU based on what someone else might be doing. But I think it's a gap within the OpenStack project. And I think that it's something that you'll see get kicked off this year and start to become less and less of an issue because there'll be more and more documentation that gets produced. In the yellow, sorry, and then you. So that's a great question too. Multiple great questions. So the cost model that I showed you was a little bit light on the private cloud side because all I took into account was the cost of hardware, but you do have the cost of humans and there is supporting hardware like network, etc. Now, you also got to add in cost if you utilize a company like Metaclod or others we have lots of competitors in this space. But what we've seen when we do models, and I didn't want to get into a price discussion in this presentation, so I left that part out. But if you look at the models, there's a significant reduction in cost from the private cloud to the public cloud. I would say in a lot of cases, and in that example I gave it was 10x cheaper. And when you layer on the necessities that you're asking about, it's probably more than half still cheaper. And then gentlemen, yes. Well, so I think it's a lot of things and this could be a very big discussion, but I think for a long time everyone thought that virtualization was going to help drive efficiency. But what you got when you got virtualization was you still had all these different business units and they would have siloed hardware that was just theirs and it was detached from everybody else, these other business units within the company by a lot of security, etc. And so you virtualized on top of that, but you didn't get the efficiencies of co-variant workloads from different business units sitting on that same bare metal. You just still had the silo and when they used it, well, maybe that's great, but typically most business units didn't. They just thought they needed 100 servers. They ended up probably using a 10th of that because if we look at the research we've done and it's been validated by many other researchers out there that the typical utilization of the server is still about 10 to 15%. The magic of OpenStack is that you get virtualization, orchestration and really it's multi-tenancy, right? It's about bringing all these business units within a company and layering all of them on top of one pool of hardware and it's those co-variant workloads that really drive up the utilization of the hardware. So the public cloud is great if you've got bursty traffic and I would still say if you've got super bursty traffic and you know it, maybe that's still a good option for you to consider because you do only pay for what you use. But a lot of companies have a tremendous amount of workloads that are known, they're fixed rate and you can really drive up efficiency and really break through that 10 to 15% utilization across the board. You know, I think we typically see in a low end 65% utilization on the clouds we deploy and typically we get utilization as close to somewhere between 80% and 85% utilization. Anybody else? Did that answer your question by the way? Okay, so now I'm starting to understand your question a little bit better. So Build Back and Show Back does help and so we've had a lot of customers ask about this very problem because you get, humans are just naturally greedy I guess. Maybe that's a way to describe the problem. So you can do very interesting things like sprawl control and go out and see, check if those VMs are actually being utilized and if they're not, you can enforce something that trims back the amount of VMs that they've got or you can just send them a big bill. There's multiple ways to address that. I don't know if any of them are really elegant but I think appropriate policy probably helps as well. Letting someone know that if they, if we do find that you're not using them, you know, a couple of them are going to get turned off or you're going to get a big bill. A gentleman in the glasses right there. It's a little hard to see back there. So that, I'm not sure I totally understand the question but I'm totally going to try to address it. That sounds like a problem for Amazon which I'm not that concerned about. But if you just look at what exists today, right, I mean as I said at the very last slide, the public cloud market is big but the private cloud market is massive. It's huge. That's why I said, you know, the enterprise server market is a $55 billion market. It grows by a billion or two each year. It's massive. So, you know, I think for MetaCloud and, you know, probably others, we're going after that Fortune 5000, maybe we're going after two verticals. The Fortune 5000 and the small and medium enterprise, these very fast, very rapidly growing startups that began in the public cloud and have exceeded that threshold. They get the call from the CFO going, what in the world is going on? We're addressing those issues. If we cause pain to Amazon, that would be a personal goal of mine maybe just to do it. But I have a tremendous amount of respect for Amazon. I mean, they've been innovators since day one. They've kind of created this market. So, you know, I don't know that that will be a result or not, but I think that that's something that they'll probably learn to adjust around, navigate around. I kind of agree with that. You know, maybe I don't know the answer to that question, but we're in a room full of innovators here and potential entrepreneurs that will probably solve that issue. Maybe it's us, maybe it's somebody else. Guy in the blue. Well, I mean, I think if you're a startup and you're in Amazon, Amazon's got this huge, you know, suite of tools that you can use and it's great for a startup too, but I think that's kind of a caveat. If you're a startup, I would just caution against if you are great at forecasting kind of what your future is or you're really considering your business model. Those are issues you need to consider before you start consuming those services. They're great services, but that can lead you down the path of vendor lock-in. And ultimately you could do something to get out of that, but it just, it ratchets up the pain for you as the startup or company that's trying to exit Amazon and onto something else, private to you or other. So you have to consider those, if you make a turn down that road, you have to kind of understand the consequences. Gentlemen in the back. So all I can say at this point is, well, so Amazon, the two largest products that they've got is Amazon EC2 and S3. So you've got a very valid question. We've never seen that issue before, so we've never had to solve for it. So I wish I had a better answer for it. I wish I could say, you know, we've went down this path and this is what we did, but we haven't. So it's kind of hard for me to construct an answer for that, you know, specific question. Well, I think the largest or the biggest problem, did you repeat the question? What's the, you got me. What's the biggest problem that customers probably experience, I guess, and let me know if I destroy this reinterpretation of what you just said. What's the biggest problem that customers face when they move out of the public cloud or Amazon to a private cloud? And I think I'd probably have to say it's that cloud engineering or cloud operations team, right? They went from a solution where they just simply consumed infrastructure, and now if they're making the choice to go down OpenStack or something else, a private cloud we'll call it. They've now got to support that private cloud. They've got to bring in the in-house talent to support the underlying infrastructure, the cloud layers, and other layers, etc. So, you know, I think that's really the premise of Metacloud. We did a lot of research early on and kind of understood that there is this problem where you have small companies or SMEs that come out of Amazon and want to build on a private cloud, and they have to address that issue. And then you've got all of these enterprise companies that, you know, at scale, infrastructure is just really, really hard to operate. It's hard to manage. It's hard to operate it efficiently at scale. And that's just really the DNA of the team at Metacloud, and that's really what we're good at. So, I would say that's probably the biggest issue they have. It's a little hard to see back there, but the light's really bright. Lady in the green, please. So, it was a little hard to hear, but you're saying, what's the financial point where someone moves out of the public cloud into a private cloud? So, all I can say is what we see. And I think that, again, when customers inside of a public cloud get to about that $100,000 per month spend, you get a call from the CFO letting you know that that's a pretty big spend. And I think, you know, the math starts to really take a turning point against being in the public cloud versus hiring either your internal staff or leveraging solutions from open-stack providers. Hopefully that addresses your question. I think it's different for everyone. So, I guess I don't want to speak on behalf of someone else because, you know, drivers are different for every company probably, but I think that's kind of the common threshold that we see. Did you guys go to sleep? Me too. If anyone else doesn't have questions, I will wrap it up. You can... You mean just like legacy apps that sit on... Yeah, that's a great question too. So, we see customers, you know, specifically large customers that probably had an application sitting on, you know, a bare-metal server moving those applications right into a private cloud too. I think, you know, we try to... We're working usually with existing hardware when we go into an enterprise and we try and construct a private cloud to accept generalized workloads because we really have visibility from the hypervisor down to the bare-metal and from the OS up, we don't really have a lot of visibility and of course that's kind of how customers want it anyways. But what we see is, you know, customers will put, you know, almost anything in there and we see a lot of success. We don't really see a lot of issues that people would think that they have. We always get questions from analysts or investors what's the perfect workload that you would put on a private cloud. I don't really think that there is one. I think that, you know, in today's technology stack, KVM for example there's about a 5% overhead for that hypervisor. It doesn't really make that much difference and I think that there's a lot of positive that you get by putting it on something that can handle orchestration and virtualization. For example, if you had a server that was going bad, it had memory issues or hard drive issues the ability to live migrate that VM onto other bare metal I think is much more advantageous than worrying about that 5% overhead. So, you know, I would say we've got a customer that's got 6,000 different and distinct applications. It's a lot. Most of those applications at this point have found their way onto the private cloud that we operate on their behalf. So the fact that, you know, that's true lets me believe that almost anything will run successfully on a private cloud. I appreciate you all attending this discussion. Thank you.