 Okay. So welcome to this presentation. I am Bruno Morel, I am a software director of iNAP. We are a public company that is using only OpenStack to provide the infrastructure. Hi, I'm Jean-Elyel Bonto. I'm from OVH, I'm a technical evangelist. I will give some details about OVH and public cloud like Bruno. And my name is also Bruno. I'm from Catalyst IT. I'm the general manager of cloud computing there, but I started as a solution architect and have gone through the whole process of Catalyst developing and implementing a public cloud in New Zealand. And based on that experience, I'm actually in the context of this presentation, not representing the Catalyst public cloud, but instead OpenStack as a private cloud solution. So I was helping these guys to develop a total cost of ownership model for an OpenStack private cloud so we can compare prices for data with public cloud providers. So that's the subject today. So it's gonna be can OpenStack beat Amazon Web Services in price? So it's reloaded because we did that presentation in Barcelona already, but we augmented it and I like my metrics, so that's why it's really a bit. Reload it. Just a little quick. At that presentation? Cool, thank you. I was supposed to. Okay, cool. So that's a big and complex subject. So the way that we approach it because it's kind of an Apple and Orange's problem is that we try to simplify a lot of the stuff. So we're gonna start with just explaining the principles that we've put forward to be able to compare those Apple and those Orange's. Can you guys hear me now? Oh yeah, better. Thank you. So what I want to show you together with these slides at the end of the presentation, you guys will see a link in a QR code to a Google Drive folder that actually contains the spreadsheets with the calculations that we've done to come up with these numbers, right? So the idea is for you guys to be able to understand the assumptions, understand how we arrived at those numbers, and also make sure that whatever assumptions we've made apply to your business or not and change and tweak it as you desire. On this slide here, what we have, just to show you, for the private cloud, the total cost of ownership model, what we are using as a reference there is a large private cloud, right? And by a large private cloud, I'm talking about something that will have 300 compute nodes, 50 object storage nodes, 40 block storage nodes, so something that has got a certain scale to the point where to run this cloud in production over a period of three years, you would be spending something like $11 million for the whole thing, hardware people, power, location space, and so on. But the important thing is, if you were selling this capacity, either internally as a charge-back mechanism or actually as real money being transacted between companies, with the margin, with the cost that we are using there, you would actually recover that $11 million. So what I'm trying to show here is that the numbers actually stack up and that we have a valid price model. My intention there was not to add a margin for profit, it's a margin for cost recovery only. And the reason this is important is because when I'll be talking about the private cloud numbers, I'm trying to show you what the bottom line is, right? What is the cheapest price that you would get at a certain scale with OpenStack? Yep, so that was basically the first dimension that we looked at. What is the baseline? What is the minimum cost that you have if you just do it yourself? The second part was to use, of course, Amazon as a reference. There's a very interesting and useful tool that you probably already have used, which is called the Simple Monthly Calculator for Amazon Web Services, where you just enter the kind of instances that you want and you get to fill it all up correctly, and then you get an estimate of your bill. So inside that tool, this is something that we think is very useful to our point of training to make. It's basically there's a template of workloads. So we are using those templates that describe the different instances that Amazon consider a safe bet for that kind of workload as a standard, as our reference for the workload in question. So now, of course, we need to match up the different component that Amazon is using is a store in our own service offering. So the way we start it is with the hardware. And first, the CPU, because you cannot compare prices if you don't have the same amount of calculability of computation available to you. So the first, the CPU, the second was the RAM. Of course, you need to run those in somewhere. And the storage, especially the type of storage. So if you compare SSD to spin disk, that's obviously not exactly fair to any of the provider that you are comparing with. So that was our first dimension. The second dimension was location. So then again, it's really complicated. There's a lot of different region in Amazon Web Services. So we try to smoothen it up into the two main region. So that's gonna be for DUS North Virginia where you can find all the different services that Amazon provides and at the cheapest price possible from Amazon. And for Europe, we chose Frankfurt. But there's a bit of nuances. Yep, and about location. As Bruno said, location matters because we will see in the following use cases that US provider like AWS will have better prices for the same product than in US than in Europe. And for a European provider for the same product, the provider will have better prices in Europe than in US. This is the first constat. And then we have some explanation about the differences. The first is the charges when you run instance in, for example, in US, you will consider the charges in the US, especially for electricity, bandwidth, hardware and many other things. So an instance running in US is based on the US charges which are different from the European ones and the New Zealand ones. That's the first thing. And there is something related to the global strategy of the company because the prices could be based on where the workload is running or where the customer is based. And this is really related to the company strategy and it's related to the US dollar value. So all these things are really complicated to make together. And we try to simplify everything. So what we did is, as you said, we took the region which are near or as much as we can and we converted all the prices in US dollar. Yeah, so all the prices are in US dollar and we use the per hour price basically. So you wanna have all the complication of dedicated instances, reserve instances and a different dimension of monthly bidding, yearly billing and so on and so forth. I would be happy to add that if you want to look into the spreadsheet and be able to deal with it. And I just want to add one thing to that. If you guys were at the last presentation in Barcelona, you may remember that I was actually using the New Zealand cost for hardware transformed into US dollar as our cost for servers, disks and so on. And that's because back then, that's what I had access and knowledge about. But for this presentation, what I've done is to actually come back to the US market and find for that bill of materials, the local prices for all those components that we use. So now the private clouticio model on that drive, you will find that there is a version saying US dollars. That's using local hardware prices, right? Yep, and so the last part was what we call service and guarantees. Basically again, there's a lot of difference of capabilities between all the different public clout and even a private clout if you install it yourself. And Amazon also is delivering a lot of different services that we often doesn't have an open stock or not in a fashion that is multi-tonnet or in different ways and so on and so forth. So the way that we reduce the complexity with that is that we said for everything that was too complicated and too hairy, we would reduce it to the basic instances of compute storage and bandwidth that would be pertinent for that workload. So for example, for elastic load balancer, you don't need a big giant VM with a lot of RAM. So we match it up with an EC2 instance that would make sense for that workload. So what we did though is that we added and we will talk about it a bit later, we added a bit of a sysadmin slash DevOps time to compensate for the work that you have to do that Amazon would be doing for you, okay? So that's the way that we make it fair is that we don't use the services so we have to provide the capabilities to our customers slash developers, whoever they are. In our use cases, it's mainly the case for the database and the service. Yeah, exactly, most. So now, if we take some example and we won't be going through all of those, again, there's a spreadsheet with all the numbers you can dream of. So I would strongly advise that you look at it and we're gonna share the link to it. But if we take the simplest of comparison, which would be one minimum instance, it's gonna be for Amazon, one vCPU. So we're gonna match it, one vCPU for our internet, one CPU for OVH and one vCPU for the private cloud. Same thing with run and then it's starting to get complicated because Amazon does this thing which is there's 3.75 gigabyte for the small configuration. So then again, it's difficult to match because we don't do 3.75 gigabyte. So we chose to go with the four gigabyte. That's kind of fair, okay? So for the 250 megabytes that you're missing. This is an important point. Every time there is a difference that we don't find, say, a flavor that matches precisely one and the other, what we're doing is to give Amazon the privilege, the advantage of going with the smaller instance. And on our side, we're choosing a flavor that is actually higher than that, right? We're trying to be fair with that comparison as much as possible. So we should be more expensive than in and of an honor. And last, and so it's storage. So the capacity itself, again, is not the same but we make sure that it's always SSD when it's SSD, okay? So that's an example. One other category, or maybe not. Something's not happening. Sorry, technical difficulties. Oh, there you go. Okay. It looks better. Yeah, it's easier. Sorry for that. Okay, so a second example would be a more complex and more complete hardware for, for example, the relational database. So for example, for Amazon, it would be 16 vCPU, 30 gigabyte of RAM, and SSD with 320 gigabyte of storage. On our side, we do bare metal on ironic, on open stack. So we match it up with something like 16 core, 32 gig, and two terabyte spin disk. That's the high level spin disk with red hardware. So it's fair in the sense that you can split it up and make a red array out of it. And for VEH, it's gonna be a big VM. So it'd be 260 with 16 core, even more RAM, 60 gig of RAM, and around the same amount of SSD. And on the private cloud of things, part of things. Yeah, it's important to see that when I do the private cloud TCO model, I don't really like this thing of bundling storage into your compute prices. To me, compute is compute storage is storage and you can have them separate and buy as much storage as you would like for your good volume, your ephemeral volumes in that. So you can see that all the private cloud prices, when we're talking about compute, it's pure compute, CPU and RAM. And then we have a separate charge for block storage, be it based on SSDs or a combination of SSDs and an NVMe cache in front of it. And for the OVH instance here, it's a 17 cores. It's an instance without over commits. That's why we can say that the advantage is on the AWS side because we have 70 cores here and the resource is guaranteed. There is no over commit on the instance and it's not the case on the upper line. And last but not least, so the object storage, we're gonna compare S3 with Swift on our side, on open stack and EBS with Cinder and Ceph on the private cloud power. So shall we? So go ahead. I'll cover the first one. So the first use case there is a simple marketing website. So a really simple topology or architecture there. You have a load balancer, which is an M1 small computing sense. You have two web application servers that are being load balanced, each one with four gigabytes of disk. You have two terabytes of object storage and you have one terabyte of outgoing data transfer in that scenario. And as you can see, that's the monthly price if you were doing this with AWS, how much it would cost per year and then the price for internet OVH and the private cloud. And you can see that the private cloud costs, assuming you have a large private cloud is much lower in this case. And you have one more. Yep. Yep. And you can see the difference between AWS and the two open stack based cloud providers for this scenario. So yeah. So you can see that just even for a small website that only have three nodes, some object storage and quite a huge load of bandwidth, you're still being at an advantage if you choose open stack for your public cloud. And even if you can afford to have a private cloud and you're even kidding it technically. And once again, we tried to simplify everything. So we took only the hourly prices. So even if you have a column with year, it's with hourly prices for AWS for each of us. Yeah. So you can even get even more rebate but of course you could on Amazon. So that's the way you compare. So if we look at the split. Yeah, this is important, right? So for every scenario we have there, you will find a breakdown of that cost. And you can see that the breakdown in this scenario, you have 22% of the cost going for storage, 40% for compute, 37 bandwidth and a little portion there for API requests on Amazon. But the reason we wanted to show this breakdown, first of all is to show you that a lot of times when people are comparing their private cloud or their public cloud providers, they look at the storage cost, the compute cost, but they forget or don't estimate the bandwidth and the API requests. And actually, depending on your scenario, your bandwidth in this case combined with the API requests is about 40% there of your costs. So it's really important. Look at the bandwidth, look at the API requests. And the other thing of course is it will allow you to compare just the compute portion with the compute portion of the public cloud providers, for example. So it helps you to visualize that. Yeah, and so not only are we cheaper, but for most of the public cloud provider on OpenStack, there's a lot of different things that make the difference with Amazon. API request being one, the bandwidth also being a big one. So for example, as we give you a huge load of bandwidth quotas like in the 10 of terabyte per node. So that's huge. You can go overboard wherever you want and you're basically unlimited. So that makes a real difference even for the smallest of website if you get the traffic that goes with it. So now web application. So it's a bit of a more complex setup. It's a more classical setup. You get basically three web fronts with one old balancer, which is not redundant, it's not good, but that's the way it is into the template of Amazon. You get two basically application, web application server. So that's where you would be running your Apache, your PHP, or Python URL, or whatever with some storage. And then you get two database, one big relational database and one non-relational database and some object storage. So that's a more, I'm consuming a lot of relation and non-relational information, a bit of a big storage and the rest is dynamic and serving assets basically. So what it gives you again is that if you look at the prices, you get a rebate wherever you choose as long as you go with open stack. For us that's gonna be 10% for this you're gonna be 20%. And of course again, the private cloud, if you can afford it, is gonna kill everything else down the drain. So a lot of people ask, why people are doing private clouds, right? Why people are still doing private clouds? And the reality is, if you have a certain scale and the need to, the costs that you can achieve with a private cloud compared to public cloud providers is still quite substantial. So that's one of the reasons people continue to do private clouds. Side food notes on this workload, on the IANA part, we are using the bare metal. If you want to look into what does the difference make between a VM and a bare metal price wise, you can look at it. If we look at the splits again, we see that on Amazon, the compute is getting large. So the compute is getting large, you need a lot of RAM and then it's gonna cost you more and more and more. But one thing that you should note, and in that case, we respected the template of Amazon where there's not much traffic on that specific workload, which is a bit weird, but they used it so we didn't change it. But still, the bandwidth and the API requests are not unconsequential, okay? They are amounting about 3% of something that's already in the 10,000s of dollars per year. So that's something that you have to look at, especially since if we look at the open side provider, you won't be paying for that mostly. The second thing that you can see on the split is that now we get big database. So you would be using DynamoDB or something else. And so we added the DevOps time, that's the small grill apart that you can see at the end of the different splits for the different providers. And still, with that amount of system in DevOps time, we are still cheaper than just using the APIs of Amazon. So think about it, sometimes it makes more sense to not use those services. Yeah, not necessarily more convenient though, right? Because now you need someone running that database on your behalf. But I would expect that more and more open stack public clouds will have things like databases and servicing production. So yeah. Now that's the interesting slide for those of us that are serving for summer that are not in the US. One of the things that opens like give you is choice. And what choice give you is that, for example, if you have a provider that's specialized and that's based in Europe or precisely in France, like of the age, then you can have a huge difference in the overall cost that your infrastructure may have on Amazon and on an open stack provider. For example, in that case, with OVH you would pay $9,000 in the US because, and it's even cheaper than Amazon. But then, and if you look at the European price, you would pay 20% less even. And for us on our side, and up we don't make a difference in the two prices. Which is good too. Yeah, which is good because it's already cheaper than Amazon. So just think about the fact that by having choice, you can choose the right provider. There's provider in China, there's provider in New Zealand, there's provider in Australia. With using open stack, you are not dependent on Amazon deciding to have a region on your backyard. You can choose whichever providers have used the best for the best price, which is a huge difference. And one of the most interesting ones is the mobile application workload. So there's a huge traffic, that's a mobile app, so it's basically an app that's asking for API's answer every minute. There's of course a bit of a web front because you need those API to answer in HTTP. But there's two big instances of database, two big instances of non-relationing, database, your MongoDB, whatever, and a huge load of object storage. And then again, if you look at the overall picture, you'll see that if you choose open stack, you'll get a 15 to 25% rebate just by using a technology that's open and free. Not only could you use the public cloud of open stack, but you could use a private cloud of open stack and then you will even divide the price by basically 90%. So if we look at the splits again, and now it's getting interesting, there's a bit of bandwidth that's going on and so we are talking about $25,000 a year and 17% of $25,000 a year is not something that you want to just throw out of the window. The compute again on Amazon is still priced in a way that it makes it the most costly part of your bill. The storage is not so much important, but there you can see that bandwidth and API request are starting to make a difference. So the more you are really using those services and the more it costs you, and if you choose open stack, then you're gonna not have to pay for that. That is all the public cloud provider that I know of. Don't pay you for the API request and even most of the bandwidth. And again, in the case of VH, just anecdote, I think it's the storage, the communication between the storage and the instances. Am I right? The 2%? Yeah. And just to be fair, as the catalyst cloud in New Zealand, we do charge for bandwidth data transfer because we are in New Zealand and network traffic there is expensive compared to other countries. So it's an important cost component for us. Yeah. If you look at the location again, use difference. So for Amazon, you would pay 10% more in Europe. So which means that if you want to be near your user, you would have to pay more. When if you choose open stack, you would have the opportunity to choose OVH where you will be paying 20% less. Compared to their US price. Compared to the OVH US price. Correct. It's not 10% of the OVH price. Yeah, good. So again, amazing difference. Yep. Archiving. The last use case about archiving. So just one word about our services on our public cloud archive service. We built this service a few weeks ago. We prodded it a few weeks ago. And in fact, it's based on Swift. And you can address your archive account with a Swift API, classic Swift API. Or you can do it with SCP protocol, SFTP protocol, or I think. Yeah, and in fact, it works like AWS Glassi. You can push your data to the archive service. And when you need to recover your data, you have to work them up, make a call to work them up, wait a certain time. And then when the data is available, you can get your data like in AWS Glassi. So in this use case, we have the situation of a huge system and we want to archive all the logs. So every month we have 500 gigabytes, five new 100 gigabytes. And we want to push it on the archive service. And if you do it for 10 years, you will have 70 terabytes. 60? 60, sorry, 60 terabytes. And for the outgoing traffic, we estimate that the situation requires something like, sorry, 50 gigabytes for log analysis when you want to get the log and analyze something or, yeah. So, yes, the prices, as you can see, we are cheaper than AWS, one more time by 25%. And here the interest in the industry, interesting things is that the green part is what you are interested in. You want to pay for the storage, right, for when you use an archive service. So here you can see that you really pay for a storage. This situation is the situation after 10 years of archiving logs. So that means that you already have 60 terabytes of data in the service. And here you can see that the bandwidth, the API request is not really important in the budget. But if you do this calculation for the first year, for example, you won't have the 60 terabytes already in the service. So you will have the bandwidth and the API requests, which will represent maybe half of the budget, really big part of your budget. Can I say something? Yeah. I just want to acknowledge that it's no small feat. I remember when Glacier became available and we were all very, very impressed with the cost per gigabyte for archiving data in Glacier. And to me, it's no small feat that OV8 managed to create a solution that can compete in costs with Glacier. So I think on behalf of everyone here, we would like to say congratulations for you guys for doing so. Thank you. And at the same time now, where in my community head, I'm really interested in seeing whatever changes you guys have made to Swift, hopefully being open source then becoming part of Swift upstream as well. Because it looks like a really good contribution to the Swift project. Yeah, we are working on that, yeah. Excellent. And the one dollar. Yeah, as you can see on the last line, for AWS, like previously, you have a huge difference between US and Europe. And for OVH, you can see that there is one draw between US and Europe. So if you want to choose, maybe you can buy a coffee with this one dollar if you go to Europe. Fill coffee from OVH. I think. Next one. Okay, so, oops, okay. So, can OpenStack beat Amazon price? I would say that yes, it is possible. Not only it is possible, but honestly, the more I look at it, and I would say that it's even easy. What you have to remember is that the cost is not just the cost that you can see on the website. The cost is your workload cost. So if you take a holistic approach, you get to people for that bandwidth. And the more you consume it, it's gonna amount to a certain price that's gonna be different than what you thought about. And those API calls, again, they are not free. So you get to take them into account. Unless, if you're using OpenStack, most of those goes away or are reduced in a very important fashion. So we wanted to leave you with something to think about is that not only is it important to look at it at a short-term span, but also as a long-term investment. So this is my ideal idea of what should be the curve of any company. So you get no experience in what you are trying to put on the web. And so you get to learn. And what happens is what I call, you enter the purely public cloud Iceland of Rambos. So you want to, you know that Amazon is easy. You want to use it. It's fun. There's a lot of APIs. It's restful. It's super fun. You love it. And you get to VM to run. So it's okay. You can use GMR maybe if you do some not produce and stuff like that. May I say that everything you said also applies to OpenStack, right? Restful. Yeah, it's fun to use. We all are included in the public cloud slice there. And then life gets complicated. Either you are on Amazon or any other public cloud provider. And so you're starting to enter what I call the hybrid land of chaos where you try to optimize your workload. So do I need a medium here? No, I don't. I want a small here. It makes more sense. So I'm going to optimize for that. Or I want a bare metal there because that's the workload. I know that I need it. And I know that you need to use all the CPUs. I'm going to put a bare metal here. And last but not least, if you go that far, you're going to enter what I call mostly private cloud of mundane of wise old wizards. So you enter recovery. And then you basically at some points want to do it to yourself because you get the money to be able to do it. You get the money to maintain it. And so you're asking yourself, why am I paying someone else to do it for me? You can still have good reason to keep it on the public cloud. But my point is just at some point you're going to ask yourself that question. I actually would like to provide an example. You guys probably remember the story with Dropbox, right? So Dropbox started on top of Amazon AWS using pretty much only their infrastructure. Eventually they got to the point where they had some hybrid. Some of their servers were running outside the cloud and on Amazon it was pretty much just the object storage part of it. And a few years ago, I think now, I don't remember exactly the date. They decided, okay, no, we're too big. We understand too much about running object storage in a system to store documents. We're pulling out of the public cloud and building our own private cloud for Dropbox. And now they run their own infrastructure, right? So eventually you see this pattern of successful startups growing to the point where they develop the experience and also the volume to say it's more cost efficient and strategic for my business to run my own infrastructure. And that's when they enter into the private. It's really related to the volume. Yeah, and it's important. The volume is important, right? If there is one thing that I would like to say in relation to that is, if you are building an open stack private cloud to run one computing sense or a handful of virtual machines and you had the cost that I'm talking about of a large private cloud of $11 million, I'm sorry, but that makes no sense. Buy a plane. And also to be honest, you don't need an open stack private cloud with 300 compute nodes for the numbers to stack up, right? But you need a certain volume. Maybe if you have 500 virtual machines, 1,000 virtual machines, that's when it justifies doing a private cloud where the numbers start to stack up and compare well with your public cloud providers. So one thing that I need to be honest about as, oh, sorry, is that the curve is a lie. So the curve really looks a bit more like that. Okay, so for a long, long time, you want and probably shouldn't look into a private cloud because as Bruno said, you get to incur the cost. You get to incur the maintenance cost. You get to train people and put that project forward and be able to manage that project. It's not something that's trivial. And at some point, you're gonna have to pay for that. That's not free. And so if you want to enter the maintain of why is old withered, there's a ticket fee for that. If you can afford it, that's amazing for you. That spike there is your project to implement your private cloud, right? So you will have the cost of hardware, which could be a capital investment or you financing hardware, it doesn't matter. You have the effort of that project and then after you cross that point, maybe you will get the benefit. The other thing that I didn't say in the last presentation that I wanted to say on this one is there is a risk associated with that, right? And the risk is, is your company capable of attracting the right people, developing the knowledge, the experience required and retaining these people for a while? Because one of the reasons people go to public cloud providers like these two guys here is because it has already been done for you, right? There is no risk associated with the project. That project is successful. It's running production and you just go and consume it. So the question is how successful or what are your chances of succeeding with a private cloud implementation? And that's when I really like what I see with companies like Mirages, for example, reinventing themselves and following what other companies are doing and saying, I'll deploy and manage an open set cloud remotely for you because what they are doing with that is to increase your chances of succeeding with that project and minimizing that business risk. Basically smoothing up this curve. A little bit this curve. Good. So, very happy to have to share that with you. So I'm Bonamorale, this is Greno, Lago, and Jean-Danielle Bonteau. We are accessible on Twitter, the internet, wherever you want. You can reach out. We'll be super happy. Any comments you may have if you want to have precision details? So Bono is more at ease with the TCO model for the private cloud. Me, NGD, we are very aware of the public app part. If you got any question, you want to run a specific workload into the spreadsheet, please go check it out. It's there. It's available. It's open source. It's on Google Drive, though. Because there's no spreadsheet online that's available for open stack yet. I do want to ask a favor for you guys. Number one, on the last summit, we had some really good comments and improvements suggested by the community on that spreadsheet. It is licensed under Creative Commons, so we cannot collaborate on this. And the second thing is you may have noticed that for things like the archiving scenario, I haven't developed or put their TCO model for the archiving use case. So one thing maybe we should do for the next summit is to work together in creating a few other offerings in there. I would like to see their archiving scenario covered. I would like to see costs for databases as a service, costs for other services in open stack being defined in there. So if you're interested in this space, please join me and help us to do these calculations and provide that model to the community. Yeah, and if you are from a public cloud provider, we are welcoming anybody to put their numbers in here. That the whole goal is to be fully transparent. Most of the public cloud provider has to display the price, so we can just put them there. Of course, we won't be doing that for them. That would be probably insulting, especially if the price is different. So we invite everybody to try to participate into that. Even if you are a public cloud in New Zealand or even on the moon, tell free to do it. That's the goal. Is that your next region? Yeah, secret. That's it, that's our time. Thank you very much, guys.