 So good afternoon. Here we are. We're in Hong Kong. It's the OpenStack community. That's us. It's over 12,000 people, over 130 countries. And hundreds of companies contributing to, you know, this project, what we're doing. My name is Steve Curry. I'm the co-founder, president of Metacloud. Metacloud is a software company that produces a distribution of OpenStack. We match that with the expertise of our team. And so what that means is we overlay our software on top of your hardware and your data center. And we manage it remotely. So for you, it's a lot like a public cloud experience, but it's completely private to you on your own infrastructure. And so before we get started in this presentation of the seven deadly sins of private cloud, I just wanted to share a story. Mostly because I'm right and the person that was in the story opposite of me was wrong. I was in Portland at the last OpenStack summit and it was the keynote. I was sitting next to a VC whom I won't mention. He's not here though. And they just announced that the next OpenStack summit was going to be in Hong Kong. And he threw up his arms and he was a little upset and he goes, you know, I don't understand that. I don't get it. I don't think anyone's going to be there other than people from Asia, people from Hong Kong. It's a long way to travel, clouds in its infancy. It's asking people to go a long ways to get there. I said, you know what? I think you are wrong because this community is growing like crazy. Again, it's in over 130 countries. I think there's going to be participation from everywhere. So by a show of hands, who here is from Asia? If you're from Asia, can you raise your hands? There's 10. If you're from Europe, would you please raise your hand? There's slightly less. If you're from the US or South America or places that I didn't mention, that's me. Wow. So we're going to do something. I'm going to give him a Christmas present, which is a framed photo of him being wrong. So on the count of three, if you wouldn't mind, you could throw your hands up and happiness that you're here. You're excited to be at the OpenStack Summit. If you're from Brooklyn or Los Angeles or Jersey, if you know how to throw up the international, you're definitely wrong sign. Feel free to do that too. So on the count of three, I'm going to take a photo. I'll later show my email address if you want a copy of that photo. And if you don't want to participate, but you want to take a photo of me taking a photo of me proving that someone's wrong. And it's a VC. I mean, that's not even a human being. It's a VC, so it's all right to participate. So on the count of three, please raise your hands and give me any signal that you wish to show that I'm right and he's wrong. One, two, three, please raise your hands. I already took three photos there. I will frame that and I will send it to him for Christmas and I will share with you if you wish to have a copy. Well, definitely. I'm sorry, Joe, from SwissDAC. I cannot share with you. You definitely know him, though. So thanks for participating. So the first time I heard the term cloud, it was 1998. I had a team of operations engineers and someone described the cloud as accessing third party resources outside of our network. And I thought it was a cool term. It was interesting, but I didn't think much more about it after that. And so there's this gentleman on our team now. His name is Stuart Robbins. He found out that in 1994, compact trademarked the term. And so someone was very forward looking at that company. Well, the company's not around anymore. And a lot's happened in 20 years. Clouds come a very long way. And so it's brought us all here to Hong Kong to share stories to talk about private cloud. And I'm here to talk about the seven deadly sins of private cloud. And it's not really a technical discussion. It's more about human behavior and making the right decisions. So when you deploy a private cloud, it's a success. I spend a lot of time on the road giving presentations, meeting with potential customers, going to user groups and trying to understand what's going on out there and the cloud space around the globe, how people are doing things. And so the first sin that people tend to commit is skipping the TCO, not really understanding what savings there will be or won't be. And so a TCO isn't simply to tell you that a private cloud is going to save you a lot of cash. I'm not here to hold your hand and tell you that a private cloud is the end all. It's the right solution for everything. But what are you building for? It's a great question to ask yourself, especially when you're going through the TCO process. Are you choosing the right technology? Are you making the right decisions? Do you have a tremendous amount of covariate workloads with extended periods of use? Yes, a private cloud could probably be a good decision for you, especially if you're running at scale. Do you have super spiky traffic with these very long pronounced troughs? Maybe public cloud is the best decision for you. Maybe Amazon is the right decision for you. Maybe you're a startup. Public cloud is probably a good option. So maybe you started as a startup in the public cloud and now you've reached this point to where you're spending about $100,000 per month in the cloud. That tends to be a magic number. And so if you're spending about $100,000 a month in the public cloud, you will at some point get a call from your CFO trying to figure out how to stop that pain. Because no matter how much you invest in the public cloud, and of course, yes, you can do reserved instances, but beyond that there's really no controls for you to reduce costs. You can just keep buying more and more. However, you can invest in hardware, and you can invest in a private cloud, and at scale that will save you a tremendous amount of money. Thanks to technologies like OpenStack and others. So something else to consider when you're building your TCU model, as fun as it may not be. Every time a public cloud provider reduces prices and this is going to sound crazy, but hang in there for just a minute. Every time a public cloud provider reduces prices, their margins increase. Every time a public provider reduces prices, their margins increase. It sounds crazy, I get it. It sounds really like I'm wrong, but I'm not wrong. Server price performance increases every two years by about 50%. So it says Moore's Law, it's a fact. Public cloud providers, they have hardware. Yesterday's version of their hardware can hold about 75 to 100 compute units, as Amazon likes to call them on that server. Tomorrow's refresh, which is actually happening right now, those servers can hold about 150 compute units within that one two-socket server. And so public clouds pocket that value. The price reductions aren't commensurate with the server price performance increase. It's an optical illusion. Their prices are reducing, their margins are going up, because the requirements that you have for your applications are going up. We're not doing M1 smalls anymore. We spend a lot of time surveying people when we go to conferences. We have surveys that are happening right now at our booth. We try to understand what's reality with public cloud, with private cloud, how people are consuming it, and they're starting to consume it in a big way. There's big instances, high memory instances that are happening, and that's becoming the norm. With a private cloud, you get to pocket that value. As Moore's Law happens, server price performance increases by 50% every two years. You pocket that value if you've deployed a private cloud. So in my years of being deeply rooted in this business, and I think I've seen it all, maybe I have, maybe I have, the team at MetaCloud on average, employees have been at big companies, big infrastructure companies running at extreme efficiency for about a decade. There's guys from Yahoo. There's guys from Ticketmaster. There's guys from Google. And so we've seen a lot of big infrastructure running at scale, and we understand that. And OpenStack delivers a tremendous amount of value on top of commodity hardware, and so that's got to go into your TCO. Look at SwiftStack. Joe, back there at SwiftStack, raise your hand. Commodity hardware, tremendously intelligent software, creating a tremendous amount of value. MetaCloud with CarbonOS, we do the same. Commodity hardware, a full-featured private cloud. OpenStack can do the same. OpenStack runs on most infrastructure. And so covariate workloads have to go into your TCO. You have to understand how much of these business units. So for example, you're a large enterprise, and the way your enterprise runs today is you have 60 business units, 100 business units underneath you. You're doing a lot of M&A activity, and every business unit has its own little silo of hardware, its own little group of IT. Now imagine tomorrow there's a private cloud deployed, there's a centralized IT department, and those business units are overlaid thanks to multi-tenancy on this one collection of hardware. And so what was 4,000 servers could be reduced to 1,000 servers. That has to go into your TCO consideration. And one that comes as a big surprise, I think, to a lot of people, because we hear it a lot, you hear it in a lot of conversations, is team efficiency and end user efficiency. Just the simple fact of doing self-service, being able to spin up instances easily, not having to wait days, weeks, months for someone to go to a data center, acquire the hardware, throw it into a rack, cable it all up, and present it back to you. They can now just go to a dashboard or make a simple API call and provision those virtual resources all on their own. I'm still laughing a little bit inside about that photo. This is going to be epic. Then number two, and so it's forgetting about the end user. And to me, this is a big sin. This is a big problem, and I think this is probably a major contributor that leads to failure in a lot of companies and deployments of private cloud. Let the grit and the emotion, and the heavy-handed opinions in regards to technology and your technology, religion. New hotness, everyone has an opinion. But we're here to purposely build clouds, private clouds, to drive up efficiency, drive up productivity, to reduce cost. But most importantly, we're here to build something for an end user, someone that's going to be accessing this infrastructure. And so we have to make sure they're successful because if they're successful, more than likely we're going to be successful deploying that private cloud. Build a cloud based on your interpretation of what you think it should be. Don't start building the end-all solution right from the start. There's a reason why public cloud has had such success building just very agile, very easy to consume, self-provisioning, virtual resources. And if you can't deliver on par with the public cloud, this ease of use, self-provisioning, or enabling shadow IT. So make it easy, make it easy to consume, easy to access, make it reliable. At MetaCloud, we spend a lot of time talking to customers, interviewing customers, trying to understand what their needs are because we have to innovate on their behalf. And you have to do the same when you deploy a private cloud. And this is continuous. It never stops. You're interacting with your end users and understanding their needs, understanding what they're going to need tomorrow, six months from now, a year from now to be successfully, continually successful. If you disconnect from the end user, that is if you lose focus on staying in contact with them and staying in communication and continuing to understand what their needs are, the end user will disconnect from you, disconnect from your solution. That drives shadow IT, you don't want that. We see this a lot in today's enterprise. So send number three is mistaking the beginning for the end. It's not about the start, it's about the finish. We see distributions optimizing for installation. Install in 15 minutes. Plug something in, bam, I've got a private cloud. This is just the tip of the iceberg. It's the very beginning. Optimize for production. If you look at the timeline of a private cloud, there's many components of the life cycle. The installation should be the thinnest piece there is. It's about providing a very consistent service to your end users. So we call this full life cycle cloud. It's this never-ending cycle. And it's really important stuff to consider. It's the things that you have to understand and keep doing well for you to be competitive with the public cloud to keep your end users happy. And so full life cycle cloud is design and architecture. It's sitting down with those end users understanding what SLAs you have to meet, understanding what features, what core features they need to be successful. It's platform installation, installing the private cloud, presenting it to your end users. It's 24 by 7 monitoring, understanding the health and performance of your cloud, making sure if there's an ECC memory issue or a smart hard drive issue that you can take corrective measures immediately so it doesn't impact your end user. I talk about end users all the time. It's problem resolution. So when you detect that memory issue, that hard drive issue, you suspect that a hypervisor is about to fail. It's being able to take corrective measures. Maybe it's live migrating those VMs off that hypervisor onto a healthy hypervisor and tagging that suspected bare metal hypervisor out of service until you can repair it and bring it back into service. It's maintenance. You know, OpenStack is moving at a blistering pace. There has been a lot of conversation just today about the directions of new projects. Every six months there's a major update. Metacloud is the top 20 contributor to the OpenStack codebase. We get it. We understand there's a lot of updates. There's a lot of patches. There's a lot of security enhancements. You have to be able to constantly incorporate those back into your private cloud to provide a very reliable product, to provide the best thing for your end users to consume. It's platform updates, major updates. So going from Grizzly to Havana, from Havana to Icehouse. I know there was a big discussion today about Nova Network. Rafi looks a little light in the face because of it. It doesn't look too happy. Rafi is our CTO. But in the past, when there was discussion around going from Nova Network to Neutron, that's great, right? Because Neutron's going to bring a lot of flexibility, advanced rules, but the migration path from Nova Network to Neutron wasn't really well-defined. That's on you. You have to have the migration path. You have to set up the expectations for the users. Maybe there's a maintenance window. Maybe there's an outage. How long it's going to be. And capacity planning. And we'll talk about this a little bit later. If you deploy something that's successful, you want to make sure that you can continue to provide a very reliable service. If you run out of capacity and basically any means, you provide a degraded service to your current users, and essentially you provide a denial of service to your new customers that may be trying to access the platform. So send number four. Failing to consider the new layers of IT. With new solutions like OpenStack and Private Cloud and essentially any open source technology or new technology that comes to the market. But very specifically I think Private Cloud's been a big driver for this and I think a lot of people have been in denial about it too. You know, we have network engineers. We have SysAdmins. We have storage operations guys. Database administrators. And now we have cloud operations. And cloud engineering. OpenStack again, amazing product delivers a tremendous amount of value. But you've got to have the right team to operate it and constantly innovate it on behalf of your customers. You know, probably a lot of us have heard stories of frustration. OpenStack has a lot of moving parts. It's constantly changing. The communities innovating at this crazy pace. I've also heard OpenStack isn't ready for production. Those people are wrong. And if you think that you're wrong too. With the right team, OpenStack is absolutely production ready. It's production ready at scale as well. And the problem is compound thanks to Public Cloud. If you're an analyst or a reporter please take note to this next statement. It would be a very good article title. Amazon has burned down the only unicorn factory. It's a fact and it's true. You know, five years ago startups, we received money and we'd go out and buy infrastructure. We'd go acquire space in a data center and we'd go set it up, plug it all in. And then we'd have to operate it and put our applications on it. And as our company grew, our team grew, our knowledge grew we got better at operating these things at scale. We kind of grew up with it from start to finish. I'm sure colleges are pumping out engineers like crazy but the art of operations, operating infrastructure at scale is rapidly eroding. It's going away. There's just not that many people these days learning about it because you simply just go acquire infrastructure early on when you start in the public cloud. A private cloud at scale requires a team of four to six. That's a fact. This isn't a job for the IT guy, although we've seen that happen many times and it never turns out well. You can build a team of experts. You could have the Linux guy, the hypervisor guy, the network engineer, the Python developer, the database DBA or if you're really lucky, you can hire a pair of unicorns. And a unicorn is this person with a deep understanding of broad technologies that kind of get it all. But anyone can be hit by a bus, even unicorns, so you have to have at least two. You wouldn't want to just have one and have them get sick. And unicorns love to go to new places that are exciting. The turnover rate's pretty high. You're probably not going to find these in big enterprises either. Unicorns don't like to hang out at financial institutions. They don't like to hang out at manufacturing places. They want to be where all the excitement is. They want to be in Silicon Valley, Silicon Beach, the tech hub of Asia, the tech hub of Europe. Unicorns are worse than koala bears. They have a very specific diet. They want to work on the newest technology. They want to work on the thing that's just right around the corner that's the most disruptive. So good luck finding one if you can. Or you can bring in outside help. An outside team to help you operate your infrastructure, like MetaCloud or like others. Sin number five, overlooking the value of existing infrastructure. You know, it's like a birthday card or a Christmas card that you got last year. It's time to re-gift that infrastructure. When it comes to cloud, I rarely hear people talking about utilizing existing hardware. I hear a lot of people talking about go buy new hardware based on something very prescriptive. Maybe it's the blistering pace of technology and how companies have grown used to just solving problems buying more. Because I see that a lot. Let's just buy more. Let's buy new. Here's something to consider. There's a $56 billion server market out there. And on average, the utilization of those servers is about 10 to 15 percent. It's really low. And even though utilization is low, companies keep buying more. If you look at the trend for this $56 billion market, it grows every year, regardless of the economy. Sure, you can take a purest view and you can go green-filled, but in business value creation is key. Cloud is still in its infancy. So start small. Start with what you have. Make it very agile. Make it very easy to use. Enable self-provisioning of your existing hardware. There is a tremendous opportunity right here with large enterprises to take their existing hardware and create a tremendous amount of value. And so I should have skipped to this slide earlier. My apologies if you want to take a picture of it. Yeah, please go ahead. Let me try to drive a car. I can't even drive a presentation. So second to last, deadly sin. And it might sound a little silly, but inadequate marketing. If you build it as they say, they will come, yes. And if you build something where you make your end-user successful, absolutely they will come. But only if they know about it. And this really applies to large enterprises, but you'd be surprised how often we see something like this. You have to let them know the solution exists. You have to build a private cloud. You have to be transparent about your roadmap. You know, this drives collaboration. It drives conversation. And I think that ties back to the life cycle. It's this constant communication with your end-user, which I pretty much talk about through this whole presentation, because I think they're one of the most important components of a private cloud that you're building for. They need to be pretty much connected to your innovation cycle at all times. So they also need to be tied to the marketing cycle, too, letting them know what new features are coming. And so they can tell you, hey, I didn't see anything listed about this specific feature, X, Y, Z. And it's very important to me and the company and my project timelines. And you can start the conversation about enabling and innovating for those feature requests. I did it again. I'm going to get it right on the last one, and we just rolled through the sixth one. So the final sin, and I even made a mark here to push the button, so I nailed it. The final sin, so they came and they crushed you. You built something that was highly valuable to your end-users. And now it's very popular within your organization. Plan for success. You know, plan well, execute well, measure twice and cut once. End-users need capacity tools well, so it's not just about you making sure you have capacity for your end-users. They need to be understanding what's going on, too. You know, they have project roadmaps. They have deadlines. They know when they're going to be needing to roll out virtual resources. So they need to know what's available tomorrow. They need to know what's available in the future. Again, it drives collaboration. It helps you stay on budget. And most importantly, it helps you deliver something very successfully. So ladies and gentlemen of Hong Kong and Europe, America and all the places that I didn't mention, thank you for coming to this presentation. If you have questions, I'd be more than happy to take those. And if you want that photo, Scurry at MetaCloud, where you can tweet me on Twitter, Sol Scurry is in the city. We'd be happy to have a conversation and we can continue it offline as well. Cheers. You, sir. So I didn't mention it as one of the seven. And of course there's way more than seven. But, you know, I based it on what I see and what I hear when traveling around and talking to people. And so what I don't see is a lot of hybrid cloud. I hear a lot of people talk about hybrid cloud. I don't see a lot of it. I see people in public cloud. Or I see people deploying private clouds. Or I see people not deploying private clouds and having things like Shadow IT where they're out of policy and accessing the public cloud. But I never, I can't say I never, but I rarely see cases where people are really leveraging hybrid cloud. So it just, it wasn't one of the most common seven. Yeah, well, for example, yes, we do help a lot of customers come out of the public cloud like Amazon onto a private cloud. And the way our distribution works and a lot of other distributions work, they can ingest an AMI verbatim to make any changes. So it's pretty easy when they're coming from a public cloud like Amazon into a private cloud based on OpenStack. Where we see things get tricky is when we're working with a customer that was previously a VMware customer, helping them migrate those images onto the platform. We help our customers do that. If they have a lot of them, we provide them with a toolkit so that they can help themselves. But I would say that's probably the most tricky is coming off of a completely different private platform onto something like OpenStack. The gentleman in the blue, yes, with the mic. Yeah, I have the microphone, I guess I get to ask a question. So you just mentioned about the, or the deployments of hybrid cloud. And my follow-up question would be, do you think that's partly because it's hard to do private cloud? We don't have a lot of workload federation and identity federation and all those other kind of gluer bits to make that link, or is it just there's a lot of talk and not much actual interest in actually doing it? So I'm not an expert in hybrid cloud, but this is my theory. I think that in the public cloud, you don't have to worry about anything. The great thing about the public cloud isn't that it's public, it's that it's fully managed. And so for companies that are trying to deploy a private cloud, I think they're just trying to get that done. Again, I think most enterprises and most large companies that are now deploying a private cloud, they find it difficult once they get it up and going and in production to actually scale that thing. Operations at scale is a hard thing to do. So once that problem is solved, once it's easy to deploy private clouds in the enterprise, then I think you'll see people progress to the next step, which will probably be leveraging both. I think in the future, you'll just leverage on-premise private cloud or you'll leverage public cloud. You'll make the decision to leverage one or the other or both. But I think you have to fix the first problem, which is figuring out how to reliably deliver private cloud. Yes, ma'am, you want to grab the mic or is he going to be friendly? You're allowed. I wanted to address your statement about the skill set. First of all, there is a very large pool of people who do know how to run operations at scale and they live in the telcos. I honestly would completely disagree with that. I think that telcos tend to use a lot of very commercial software that comes with a lot of consulting. I think that where you see people operate infrastructure at scale at high efficiency and do it very well is only in a company that has technology as their core product. So who is that? That's Facebook. That's Yahoo. That's Google. That's those companies where their core product is this very technical product. And it's a product where they have to run it very lean. Their margins depend on it. I guess we can agree to disagree because I wouldn't say that telcos are really good at operating at scale. They have big stuff, but I think they also gain a lot of help in operating that. There's a lot of great telcos out there, but we have conversations constantly with telcos. Telcos are very interested in the cloud space. It was having a conversation recently and someone said, look, maybe we'll use OpenStack to get the market quickly. Maybe we'll leverage you guys for a year and maybe we'll go do it on our own. And so I started talking about this story where Amazon burnt down the Unicorn factory and how you can easily get engineers. There's engineers everywhere. But when I talked about what it really takes to operate at scale and where you really learn that very specific skill only at technology companies like Facebook and Google and Ticketmaster, he completely agreed with me. He said, you know what? I think you're right. I never thought about that. I thought the solution was throwing engineers at it, but there's a difference between someone writing code or engineering something and then operating thousands, tens of thousands, hundreds of thousands, millions of servers within an organization. That's a very different problem that gets solved. Joe. I had a question about number six and what are some of the tactics that you use or employ to educate your users about the services that are now available for the clouds that you deploy? So it really depends. That's a good question, Joe. Thanks. It really depends on what's being delivered. So, you know, we have a customer who they decided not to leverage our distribution. You know, they didn't want to leverage Horizon. They wanted to build their own because they're good at it. It's kind of one of the things that they do really, really well. And they thought, you know what? I think we can do this better. And so they did a great job of really incorporating it into their design of kind of their corporate internet. But even after they built it, this company is big. So a lot of people didn't really know that this service existed. And if you've ever worked at a big company, once you've been there for a year or two, you probably don't go to the internet to search and figure out what's on the lunch menu or what's going on with, you know, birthdays within the organization. And that's a lot of times people are really bad at marketing technology within their own organization. So they went out and hired an internal marketer to go out and do email campaigns, to do workshops, things, and we helped them with those to really educate their end users about this new platform that was available. And so we saw adoption of the platform with, you know, a bit of a spike at first with the beta users coming on. And then when they brought in this marketer, it hockey-sticked. And it was, you know, rapid growth within the organization. That's good for us, of course, but it's also good for them because the solution that we were providing was very cost-effective form. It's very reliable and they want to be able to promote things like that. And it's the same thing with you. If you're doing it yourself, you want to make sure that you're maximizing value and you maximize value when people use that resource. So I guess my point is, however you need to do it, and there's multiple ways to do it, just make sure that you do do it because you need to make sure you attract users and inform them that this platform is available. Gentlemen in the back. Number seven, what was it? Sorry, you moved on too quickly when you were correcting yourself. That's my fault. Sorry. Thanks for pointing it out, though. Delayed capacity planning or not doing capacity planning. And again, it's if you build something and you did all the things right where you listen to end users, you have the right team, you deploy the right solution, and it's great. You got to make sure that you don't run out of capacity. So we've also seen cases, and I've heard people talk about building something, and then them running it to a point to where it's degraded. They ran out of a certain resource, and so a great way to get rid of users of your platform is to put them in a degraded state, or when they show up, they get a warning sign that says, you know, it's not available. We're out of capacity. You know, sometimes people try something once, maybe they won't try it again. So my point is make sure that that's part of your, the life cycle of the cloud that you're building. You're always watching for capacity planning and that you're also providing tools to your end users so that they know how much resource is available for them. So when they're planning for deployments of new software or new applications, they kind of know what's at hand. Don't make it a black box. Provide visualization tools. Provide some level of analytics and provide some level of capacity planning through a report or a panel they can go to to really understand what they're utilizing and what they have available to them. Absolutely. Yeah. I don't know if anyone can hear you, but make sure you know the lead times on your hardware providers so that you can get that hardware in appropriate amounts of time. So, you know, maybe have a watermark at 80%. I was using that as an example, but when you surpass that watermark, it's time to start ordering new hardware, making sure that it gets into the data center in an appropriate amount of time. You. You're doing this. I wasn't for sure if I was going to get one or not. I think you went on the assumption that we've all deployed to the public cloud and only then after we've deployed to the public cloud, we deployed to the private cloud, which seems to be the way things go. In the process of that, we start leveraging things that the public cloud has to offer, like distributed databases, like messaging queues. And when we move into the private cloud, the focus seems to be only on the basic infrastructure that the private cloud offers, like object storage. How do we resolve that? And should we go to the public cloud first? So, I think it's two different problems. I mean, Amazon and the public cloud, they're trying to attract users from all over the world. So, they have to provide a very broad set of tools to try and attract everyone. When you're building a private cloud, you have a specific, more than likely have a more specific type of problems to solve for. So, my original point was, focus on delivering something easy to use and reliable at first, iterate on that ongoing. And that's about continually engaging your end users and understanding the features that they need and making sure that you constantly innovate and provide those features. So, start, provide something reliable and get to the point to where you're talking about where you have all the features that everyone wants. And it doesn't stop there. In the future, they're going to need new tools to be successful. So, it's a constant innovation cycle. Anyone else? Thank you. Really appreciate it.