 Okay, we are good to go. Good morning and welcome. Thank you for attending this session. My name is Massimo Ferrari and my partner in crime here is Eric Maurisi. We both work for Red Hat. We are part of the team responsible for the product strategy in the management view. Today we are going to talk about the financials behind the private cloud, and specifically a private cloud based on OpenStack. If I will be able to change the slides. There we go. Before starting drill down into the model, I'd like to provide a little bit of background on the project because we started this research as an internal activity. We were looking to a number of answers around OpenStack and we had two big questions. Okay, I need to build the private cloud. Is OpenStack the most cost effective technology that I can choose if we compare it with other known OpenStack technologies? And okay, I have my private cloud up and running is based on OpenStack. What are the first thing I should focus on? The knob I have to turn to make my private cloud even more efficient. So we started running through a number of TCO model already available on the market, but honestly, none of them was transparent enough, deep enough, able to provide the level of detail that we were looking for. So mainly because our lives were way too easy, we decided to create our own model for the TCO. So what you expect to see today is something slightly different from what you may use to. Because it's not the usual marketing tool that we made to prove some point convenient to us. Is we tried not to seek the numbers themselves. We tried to build a tool, a way to provide those numbers in a consistent way. And what came up is a tool that is intended to be consumed by IT decision makers and support them in financial conversation within the company and with the line of business. And in building this tool, what we did is asking a number of peer review from IT guys, financial guys, people we trusted in the industry, following the exact same process that an analysis firm like, I don't know, IDC and Gartner uses when they deliver their researches. So what we try to do is to be as objective and as unbiased as we could. And to do so, we relied on industry data. But because we were about to explore a number of areas not covered by traditional research, we had to do a number of assumptions. What that means, well, basically, that some of the number that you are going to see later on in the presentation looks weird to you, causes could be only two. Or we did the wrong assumptions, or we used industry data that we're already outdated when we use them. The good news is that the model is completely transparent. That means that it's very, very easy to fix it, very, very easy to improve it over time. And because, as I told before, is a tool, that means good numbers in, means good numbers out. So what we try to do is to build the most comprehensive TCO model for a private cloud. Able to act like a scorecard, so to help you doing comparison. And because, as I mentioned before, is transparent, that means that you can use your own number inside the model. Well, to recap, long story short, we built a tool able to provide numbers to be crunched by financial guys, taking account things like the impact on income statement, balance sheet, cash flow, whatever. And has been built by IT guys, us, people who knows that things like hardware and people has different cycles within the company. And because we believe that tools are the right way to find answers, we built this tool to support ongoing decision making. Now, I don't want to spend any more time into this introduction. The important thing here is that, as I mentioned before, this was an internal research, no plan at all to share outside. But in the process of building the tool, we found out a number of, well, remarkable things. So we decided to present the research at the summit in Tokyo. We collected a number of, you know, interesting feedback there. And so we spent the last six months double checking the numbers, comparing the research with something else that came out in the meantime and we are happy to see that, you know, we were pretty much close to the reality. So let's go straight to what we found out building the model because at this part of the presentation, the numbers are the important part. The important part is what we learned into the process of building the model itself. And the first thing is that, well, good news. OpenStack is the cheapest technology to build a private cloud. Now, not exactly surprisingly, but because that's the first time that someone in the market tries to build a similar tool, we are happy to have numbers that prove this statement. The interesting thing, the relevant thing here is that we are not talking about a single use case. We are not talking about a single situation because no matter how fast you grow, no matter how slow you grow, we weren't able to find a single situation where OpenStack was more expensive if compared with other known OpenStack technologies. Now, two big statements, I know that. So it's time to provide a little bit of insights of this project, just to support what we just said. So we started running through a number of different growth curves. What we were looking for was the consistency in the results independently from the growth curve. So we run through exponential, linear, logarithmic, while those curves, because each one of those curves represent a different adoption strategy inside the company and the success that this strategy has inside the company. Well, the difference is because different type of business, different companies have different timing into adopting a new technology and have different timing into deciding and applying a different strategy. That's why you will see around companies which decided to go all into a private cloud, so moving all their applications to a private cloud. And on the other side, you will see other companies bet on a single relevant pilot project to boost the confidence in the technology. But the point here is that what the model proves is that numbers are consistent independently from the growth curve. So the numbers you will see may be different or very different from what you see every single day in your infrastructure, but the point is that the model remains valid. And because the comparative results are always the same, what we did for the sake of this representation is to use what we found the most common growth curve, so the exponential curve. So everything you will see later on relies on exponential growth curve. But what we are comparing here, as I mentioned before, the first question we were trying to answer was, okay, is OpenStack more cost effective if we compare it with other technologies? So the comparison here is OpenStack versus other vendors' technology. I'm specifying that because later on, we will see another kind of comparison which is more like buying model for OpenStack, so more OpenStack versus OpenStack. But what are the items that this model takes in account to calculate the TCO? Well, to procure and to run a private cloud, you have three main items, software, people, and hardware. And you can split those three items in three different buckets. So you will find in the software buckets all the costs related to subscription or licenses, depending on the software you're using. In the people bucket, which is the most relevant in terms of size, you will find all the costs related to server and storage administrator, network and system engineers, their managers, the training, the onboarding cost, talent retention, everything is around the employees. Last bucket, probably the easier, the hardware bucket contains all the costs related to procure and refresh all the hardware you use in your private cloud. So we are talking about servers, storage, networking. And well, the nice thing here is that the model addresses each one of those cost items in a different way. So to address the software costs, the model compare a number of different technologies to provide an infrastructure as a service engine. And to address the people cost, the model introduce IT automation at different levels of the infrastructure. And to address the hardware cost, the model simulate different VM density on top of the hardware, on top of the servers. But what we are comparing here, we say that we are comparing OpenStack versus other technologies. Now, we are not quoting explicitly other vendors, we all know who are we talking about, but the point, the relevant point here is that all the other vendors providing their bundles, orchestration and IT automation capabilities that aren't present out of the box in OpenStack. We all know that OpenStack has a lot of potential for automation, a lot of potential for orchestration, but the point is that to do an Apple to Apple comparison that we need to do there, we compared OpenStack with a CMP on top of it. And well, because we are at that, so we easily access to those data, we compared RHCI, which is one of our bundles, which includes our OpenStack distribution plus cloud forms as the CMP on top of it, which provides all those capability to compare. Now, let me spend just few moments on the notion of CMP because cloud management platform is a terminology introduced by Gartner to describe a family of products intended to augment infrastructure engines like hypervisors, infrastructure as a service, cloud manager, platform as a service, cloud managers, and introducing a number of capabilities like cell service portal, chargeback, policy enforcement, whatever. And another thing you may expect a CMP to be able to do is to spread all those capabilities across a large number of infrastructure providers on one side and cloud providers on the other side, enabling what we call an hybrid cloud. So at the end of the day, a CMP is that piece of software you may expect to see in place into your infrastructure at the latest stages of maturity. And talking about stages of maturity reminds me that implementing a private cloud inside an enterprise, inside a company is a journey, a journey that may take years to reach the full maturity level. And that's not something that we are saying, it's not something that Red Hat is saying, it's something that all the major analysis firm says. And don't get me wrong, you can have your infrastructure as a service up and running it, let's say six months. You can do that. We are talking about a different level of maturity. We are talking about training your people to this new technology. We are talking about adapting your business processes to this new service model. We are talking about introducing a number of capabilities that are needed to interact with all the enterprise tools that you have within the company. And all those things while you are driving the adoption of a new infrastructure. So not exactly an easy thing to do. That's why we are showing the numbers on a six years time span. Well, that's one of the reasons, the other reason is that we are showing the costs and how the cost changes over time. In fact, we modeled this TCO up to 10 years, which is way longer than how your infrastructure may look like now. But we were trying to ensure that there are no weird gotchas over time. And if you remember, for this representation, we are using the exponential growth curve. So you will see the number of VMs doubling year over year. And last relevant things for this representation is that all the numbers we are showing are represented through a unitary metric, which is cost per VM. That's very important. And we are going to come back later on this because now it's time for the graphs and some numbers to support the graphs. And okay, now it's the moment for my buddy here to explain why those numbers are important. Thanks, Massimo. One thing you guys will see pretty clearly is that even year over year, the costs can be dramatically different for offering the same types of services. So here we have, we're talking about the technologies in an open stack with the automation and orchestration of a CMP and a non-open stack cloud. So start off maybe $500 in savings per VM. As you get to more mature, increases to 700 or more. One of the things that we found is some of the feedback we got after we gave this presentation in Tokyo and then released our research is we had a lot of interesting comments about the numbers in particular. So one of the things is we had talked to some companies who were on the smaller side and said these are ridiculously high. We talked to some larger companies who said those numbers are fantastic. How can we get those? Those are ridiculously low. And what it looks like is we did a good job getting kind of the industry average of this because it's really kind of right in the middle. So little bit, you can see the difference between the two. Open stack is not only cheaper to begin with, it continues to get cheaper over time and you're able to get some economies and savings there that they grow over the time of your implementation. So another way to look at this is to look at the total costs over the period of time. And because open stack is less expensive as you are growing your curve, as I said, it is less expensive compared to this other stuff. The difference between the two grows even more. So by the time you are into several years in, those numbers can really, really add up. To make this a little bit more clear, we're gonna switch into another graph to look at just the gap between these two. All right, so year one, there's some difference. By the time you start to get to 1,000 VMs or so, we're talking about an awful lot of difference. So the majority of this in the comparison between the two is in the software cost. Some of this is in VM density, but that's really pretty small and we'll talk about that later. One thing to keep in mind is these numbers are list prices. Not surprisingly, other software vendors were not particularly keen on giving us their discount schedules. So in order to do like to like these are list prices. But think about the discounts that you get with your vendors and be able to, you can adjust these quickly. If we look at the cumulative savings, so understanding that building a cloud is something that you is going to not only take time, but you're gonna use over time, what is the comparative savings over that period of time, right? So basically you're getting to a point where I don't really care what your discount levels are. OpenStack can save you millions of dollars, especially as you look over the period of time. So what we just saw is the TCO model for a private cloud and the remarkable amount of money that you can save choosing OpenStack as the software solution. But if you remember the second question we had at the beginning, now, okay, we have the cheapest possible private cloud based on OpenStack. There is anything else that I can do to make this private cloud even more cost effective. Well, luckily the model says yes, but like in many other situations, the point is okay, yes, but how? And the first thing that the model demonstrates is that IT automation by and far has the largest impact on private cloud costs. And that's from day zero. So the first recommendation here is to focus on IT automation first. So Massimo said when we started off that we tried as much as possible to rely on industry data, numbers, et cetera, that anybody in this audience could get to with no problem. One of the things that we looked at were staffing ratios for sysadmins. So one of the things that we found in some of the other TCOs that we looked at that we didn't think was enough as they didn't include the cost of the people running the VMs and the apps that are on top of the cloud. When we talk about things like automation, that's where a lot of this comes in. So we got some good staffing ratios from this group called Computer Economics. And what they looked at is the number of OS instances, so VMs plus bare metal servers per sysadmin. And they found that the industry average was somewhere around 52, 53 instances per person. Now this is an open stack crowd. My guess at any number of you have an extraordinary larger than that, but that's kind of industry average. And when we're talking about this exponential growth, we're talking about doubling the amount of VMs every single year. So you have a couple options. I'm guessing most of your sysadmins are probably not working only half days, so they're gonna need help with all this other work. So one option would be you can double your cloud team every single year. My guess is there probably aren't too many people too in a position to do that for the entire life of their cloud every single year. Another place that you can bring it in is around automation. So what the folks at the Computer Economics found was that one of the key indicators for the people that had the highest levels of the ratio of the number of instances to the admin, so kind of that top third, one of the key indicators was how much automation they had within their shops. And they found that those, even just the top third, not the top tier, but just the top third, were about double to about 100 instances. And this is becoming even more important. So within the US there's an organization called the Bureau of Labor Statistics, so US government agency, they look at a lot of things. One thing that they look at is the expected job growth across any number of categories. So they expect over the next few years, we're looking at somewhere between 11,000 and 12,000 brand new system in jobs within the US. I was like, all right, that's pretty good. But if we look at the projections for the number of VMs from IDC, we're looking at between seven and eight million. So quick math, that's about 700 VMs for every admin. Now that's gonna be spread, those number of VMs are gonna be spread across the entire team, but depending on how quickly you cycle out your hardware, that could be anywhere from 400 to 600 VMs per person very quickly in the next couple of years. So if you're not there, then start thinking about automation. All right, so speaking of automation, one of the things that we looked at, Massimo said at the beginning, we had two main questions. One is how does OpenStack compare to non-OpenStack distributions in terms of cost? And the other one is what are different ways to think about and look about how you acquire and run OpenStack? Because there's certainly any number of options to do it. So we looked at three different models. One, we looked at grabbing the upstream code and supporting it yourself. We looked at getting a commercial distribution and we looked at a commercial distribution with the CMP. So that bottom curve is the one that Massimo was showing off before. So the numbers, again, they all get better over time. But the thing to think about a little bit in terms of the cost is we figured that the upstream was gonna be significantly more cost competitive. And we were surprised that it is not. And when we looked into it, it kind of made sense, right? Because it is the combination of all the people to run your cloud, but you also need additional people to support the cloud. And as the cloud goes, both of those are required. So for a commercial distribution, you are supporting your operations of your cloud. You don't have to support the code with the CMP, with all the automation pieces. You have that benefit of just supporting your cloud, but you're also starting to basically give more hours to your sys and minns to get things done, right? You're starting to divorce that exponential growth of the number of VMs from the hiring and the number of people that you need to do. So that's nice. This is a talk about TCO and finance. What does it mean particularly for looking at the comparison between two of these? So we have the hour commercial distribution of OpenStack compared to our commercial distribution of OpenStack with CloudForms and the automation. So it's automation, it's extra software, software costs more. However, when you look at the density levels that we were looking at breaks out to about 53 bucks of VM and the savings you have in terms of getting things done as you grow, that $1,200 or more means you are not having to double your team every single year just to keep up with the growth. So tremendous savings there. One thing, another thing here is so we happen to be showing from year five, the numbers don't look too different depending on where you pull from in terms of year one, two, three, et cetera. And a lot of the literature talks about some of these technologies and the value of coming in on the more mature curve. However, we found that it's really easy to get some of these really right from the beginning. So any sysimines in the room, you've probably been waiting for everybody else to catch up in the fact that if you have automation, your life is easier. And that's exactly the reason why we recently invest in the automation tool Ansible. Why Ansible and not other tools? Well, plenty of reason, probably the simplest one is that Ansible is easy. It is easy to learn because the configuration files are basically human readable, it's easy to implement because it's agent less so it's very easy to introduce into an existing infrastructure. And well, recently we extended the support for automation to networking. And that means that you have more infrastructure to automate. But going back to the findings of this project, you may remember that I mentioned that the unitary cost that we were using to show the data was extremely important. Now, one of the things that we learned from the project is that you should track all the cost into your private cloud using the cost per VM metric. Why? Because it's a great, great way to show how good you are into introducing efficiency into your infrastructure, how good you are into providing a great service at scale. And if you are acting like a service provider, even internally, the numbers that you have are closer to what your customers, internal or external, expects. So a couple of things that we found in value in looking at the per VM costs. So one in particular, they are certainly susceptible to the timing we talked about in terms of the purchase cycles and hiring, et cetera. You're going to have people come and go, people get promoted, people leave, sometimes that's a good thing, sometimes it's a bad thing. But they're going to come in at different rates. With hardware, you've got to have initial hardware, you've got to hire for growth, then you hit the cycle for refreshing your hardware every few years. In software, what differences come in in terms of, is it a license plus maintenance, or is it a subscription? All these come in and can affect things at different times. So because of this, one thing to keep in mind, and we can't recommend this strongly enough, that if you are looking at your costs, make sure you look at them over time. Because of the way that these timing cycles happen, if you offer the exact same service next year that you do this year, your costs may not be the same. The other piece has to do is, in terms of using the VM costs, is in comparison to the total costs. So Massimo and I have spent an awful lot of time looking at the data, and thinking about it, and talking to people about it. And we look at these annual costs, and all we can see is somebody is spending a lot of money. We have no idea if that's good or bad. When we switch over to looking at the per VM costs, there is no way for me to tell from that total cost that the difference in cost between year one and year three, there's a 50% savings, a 50% reduction in cost of the VM as you go over time. So the total costs are a combination of how many things we have, so how successful you are at encouraging your consumers to adopt your cloud, as well as the cost. So if you break them out separately, you can start to get to things like all these. You can see the things that we talk about when we talk about things like these magical economies of scale. So there's one right on the screen. Now, what we have just so are two very different metrics. So we have the total cost of your cloud, which is a very good representation of how many people you have onboarded on your service, how many people you convinced to use your service. On the other side, we have a unitary metric, which is the cost per VM, and is a great, great metric to show how good you are into providing efficiency in your infrastructure. So how compelling is your infrastructure to your user? But now, the really interesting thing here is the relationship between those two metrics. So one thing to keep in mind, as you do this work to reduce the VM cost, you're going to increase the usage. So probably not a big surprise. When things are less expensive, more people want to use them, they find new uses. What we did find, however, is that when you reduce the costs, your total costs are going to rise. So when we talk about the curve and the total costs going up, if you're just looking at a cost savings mechanism, keep this in mind. So we can actually say it more strongly than this. We looked at a bunch of data from IDC over long-term trends, and it looks like for every dollar or 1% that you reduce the cost of a VM, the total usage grows by about two and a quarter percent, which is a correspondingly mean that your usage costs increase by a little over dollar for every dollar that you reduce at the VM costs. Okay, so far, we saw how to address the software cost, we saw how to address the people cost, but what about the hardware? Well, surprisingly, what the model shows is that increasing the VM densities on servers, on hardware has a surprisingly low impact on cost. Now, we are not saying that you should not track the cost of your hardware, especially at scale. What we are saying here is that if you want to focus on high-impact cost items, you just should look elsewhere. So frankly, that was a little bit of a surprise to us. We figured, hey, if you can double your density, you buy half as many servers, easy way to save some money. But when we looked at it, the difference was not particularly strong. So these four nearly indistinguishable lines are different density levels across those same servers. So industry average is somewhere between about 10 and 15, VMs per server. We wanted to see what happens if we could really crank up the density as well, so we also looked at 10 and 20. Given OpenStack has some better density properties than a bunch of other technologies, let's say you've got 15, if you were to do all the work to double the density to 30, you're talking about a savings of about 350 bucks per VM. Not chump change, especially at scale, but there are a lot of other places that you can look to save money first. And that $350 is before any software and effort, et cetera, to be able to get to that maybe unrealistic doubling of density. Okay, now we are approaching the end of the presentation, so time to do a little wrap up. So the first thing we learned into this project and in this presentation is that, well, you did well choosing OpenStack to build your private cloud is the cheapest option on the market, very good. But if you want to make your private cloud even cheaper, even more cost effective from a financial standpoint, you should enforce a number of recommendations. And the first recommendation is focus on IT automation first from day zero, because IT automation has the largest impact on cost of a private cloud. Surprisingly, on the other side, increasing VM density on hardware doesn't, but once again, everything matters at scale. The second recommendation is track your cloud cost using a unitary metric, the cost per VM, because it's a great, great way to show how good you are into providing new features, innovations, efficiency in the service you are offering. But on the other side, and that's the third recommendation, expect your total cloud cost to grow while you are seeing your cost per VM lowering. Why? Because the total cloud cost is a representation of how good you are into onboarding people in your new infrastructure. And that means high total cloud cost, lot of people using your cloud. That frankly speaking is a very good problem to have. All right, so what kind of things can we change in the model? Here are a bunch of the assumptions we made. Here are the types of industry data we used. Frankly, one thing that we would really like to see and I think the industry can get a lot of value about having more understanding about the financial impact of architecture choices upon cost. There are a number of people who do this already, right? So public clouds, managed service providers, all these folks, cost is one of their optimization parameters. It's not just throughput or latency or IOPS or any of the other ones that we have. And we would love to see more expertise grow in the industry. We think it will help all of us. We think it'll help us make better decisions when we're taking architecture choices. We think it'll help us make better decisions when we are thinking about new technologies and new projects and decisions even with, even with the development of any of the OpenStack projects. So we've done this work and we're talking about what if we were gonna open source the work that we have done. We got some very generous offers when we put this out in Tokyo, however most of the offers, even they were very generous offers, were really around data. So we're pretty comfortable that the model itself works across a wide set of data and particular customer data may or may not have any transferability to any of you guys in a different use case. Could be different use cases. Maybe you decide you want to do your unit costs instead of VMs to be this containers or whatever else, right? So we're looking for ideas. If you wanna help extend this to be able to build it into something that we can use across different use cases, different classes of software, or you just have questions and wanna figure out this is something interesting, please, we'd love to hear from you. And thanks. Okay, I think we have consumed enough of your time for today. So if you want to speak with us, hey, you have any comments, anything you want to talk with us, you will find around until we get kicked off. So thank you again for attending. Enjoy the rest of the summit.