 Hello, everyone. Thank you for joining me during this session. I hope you are enjoying the summit so far. My name is Titus Kurek. I'm a product manager at Canonical. And today I'm going to talk about private cloud price performance analysis. Price performance is very important topic when talking about the private cloud because at the end of the day, when building a private cloud, it is very important to ensure that the cloud being built provides better economics than any of the existing public clouds because otherwise, why would we use private cloud at all? We are all living in the era of public clouds where public clouds are growing like hell. Their adoption continues to grow. There are more and more war clouds being grown in a public cloud. And public clouds are great, like they provide an out-of-the-box immediate access to infrastructure as a service. They provide it through very nice dashboards. They implement pay-as-you-go billing and all of that is that organizations really love and developers really love. There is one big problem with public clouds, however, and this is what I'm going to present in the following form. So this is an invoice. I just got from AWS for a usage of some of the resources on the EC2 platform when preparing a demo for the next presentation during the summit, which is about microstack and open stack on rail solution, which I'd invite you to join as well. So as you can see the problem here is that public clouds charge for everything. So if you're running workloads on a public cloud, you're getting charged for the amount of instances being run, you're getting charged for the number of amount of storage you're consuming, you're being charged for the bandwidth being consumed. And the problem here is that this approach simply does not scale and is not code effective in the long term. So if you think about it by an analogy, if you're a small company that is about to have an office, you probably won't be able to own an office since the very early beginning because it is expensive to own an office and you would probably rent an office instead. But as the number of employees in your company would grow, you would be probably looking towards owning an office because in the long term, it may turn out to be a more economical approach. And it's the same thing with public clouds and private clouds. So if you're just about to run a couple of virtual machines or even tens of them, or if you're running them just for a short period of time, like they're not running 24 per seven, then public clouds are probably the best way to go. However, if you're looking for a solution where you would be running many virtual machines, hundreds of them in the long term for years, then public clouds on scale, private cloud is a better approach. It's a more economical approach. And if you think about it, if you're at the stage where you're wondering whether you shall build a private cloud infrastructure for yourself or whether you should stay with your existing infrastructure that's most probably based on public clouds, this is exactly the reality where you are. So your organization is probably consuming infrastructure service resources from one of available public cloud providers. And you're probably working with not just a single public cloud provider to negotiate better prices. And we at Canonical would fully support you here. So you can run your Ubuntu virtual machines on any of the available public cloud providers. And all of that is fully supported on our side. But if you're now looking towards the future, if the number of workloads on your side continues to grow, if you're running more virtual machines, if you're about to run them in a long term for years, then private cloud infrastructure may be a more economical option for you. And again, you can run your Ubuntu VMs on a private cloud as well, and we'll fully support you there. Our goal here is not to compete with public cloud. And I don't believe the goal of the OpenStack community is to compete with public cloud in general. Because the actual goal is to provide a private cloud as an extension to your public cloud infrastructure so that you can decide where to run your workloads based on what makes most of the sense from the economical point of view for you. So if it makes more sense to run your workloads in a public cloud, then you shall run them in a public cloud. If it makes more sense to run them in a private cloud, then you should build a private cloud infrastructure and run your workloads there. And this kind of an approach is what we call a multi-cloud. So a multi-cloud approach is an environment where there are multiple cloud providers available, either they are private or public. And you can run your workloads wherever you want based on the economical decisions and you can easily integrate workloads and orchestrate them across various cloud providers. So the challenge here is to ensure maximum capex and opex efficiency. When building a private cloud infrastructure, it is really important not to forget about the economics. So can you really provide infrastructure as a service functionality in a private cloud infrastructure as better economics than compared to leading public cloud providers? Is it really more economical to run your workloads in a private cloud? And this is what we as a company focus. So let's now spend a couple of minutes making some short analysis of the typical IT budget. So if you have a look on the diagram on the right, as typical IT budget consists of four primary pillars. The first one are hardware and facilities. So obviously, if you're about to run an infrastructure, it has to run on some hardware. This hardware has to run in some beta center. There's a code associated with running all of those facilities, power, air conditioning, racks, cabling and MPN, the hardware itself. So this is a kind of a fixed code that has to be planned carefully when preparing an IT budget. Another portion of the budget are software licenses and services. So if you're about to run private cloud infrastructure, you're probably not going to, supported by yourself, you would be looking for some commercial distribution, providing enterprise commercial support. So that you would be safe running this kind of a software and if you go with a solution like VMware, there is a code associated to licenses. If you go with OpenStack, there's usually no licensing, but you have to pay yearly subscription for the commercial support services. So this is another portion of the budget that has to be planned accordingly. And then there is a very big portion of the budget that's usually spent on operations and maintenance. And really the significant portion of the budget is spent here. So the initial deployment of a private cloud infrastructure is usually just the beginning of the journey for the organization. The entire cloud has to be operated effectively post deployment. And there's a dedicated, there's usually the dedicated team that's providing those services and really a significant portion of the budget is spent here in internal operations and maintenance. And finally, as you have to evolve, there's usually a portion of the budget that's allocated to R&D and business transformation or a change. So our goal as currently called is to minimize the TCO associated with running your private cloud infrastructure while increasing the R&D budget and the business and transformation budget. And this is really our approach to private cloud price performance. So how do we help organizations to achieve those goals? So first of all, having a look at the hardware and facilities, we attempt to provide a better architecture for the private cloud deployment that helps to achieve the best price performance so a cloud that provides better performance results in a more economical way. Second pillar, software analysis, we provide our services at a better price compared to what VMware is doing for the appropriate staff, for example. And finally, we provide better operations to drastically reduce the budget spent on internal operations and maintenance. All of that helps organizations to minimize, to maximize their CAPEX and OPEX efficiency, reduce the TCO while still increasing the innovation by allocating a bigger portion of the budget to R&D and business transformation. So let's all have a deeper look towards how is this price performance achieved. So first of all, better operations. Our OpenStack distribution, Charmed OpenStack is based on so-called model-driven approach that allows to abstract all of the complexity behind OpenStack and expose OpenStack services and the relations between them in a form of a model so that users don't have to worry about all of those OpenStack services, all of the processes, all of the configuration files, particular lines inside of the configuration files. All of that is exposed to the user in a form of a model so that they can just interact with the model instead. And in the heart of enabling better operations is automation. And our solution is fully automated so that not only the initial configuration of an OpenStack class, but also it's lifecycle management and daily operations such as database backup, scaling out the cluster or upgrades are fully automated. And same for the integration task. So if you're about to add, let's say, an elements tax to the diagram here, these processes also fully open it. All of that allows us to provide smooth upgrades for Charmed OpenStack to new OpenStack versions, which is something that not many vendors on the OpenStack market are able to provide. And finally, this approach as the entire model can be easily exposed in the form of the YAML file is a low smooth integration with infrastructure as code and CI CD systems. So better operations are the first pillar. The second pillar is a better architecture. So as I said before, our goal here is to provide the best price performance and architecture that achieves best performance results and still is available at a competitive price. And for this purpose, we work with various hardware vendors to provide a solution that where networking is performance optimized and same for storage. And then we work with various hardware vendors to make sure that our reference architecture for OpenStack is available through those vendors at the cheapest possible price. And we work with a bunch of hardware vendors, including Gigabot, Bell, Supermicro, Lenovo, HPE, QOA and others. Finally, the first pillar is a better price. So Charmed OpenStack from Canonical, its design and delivery is available at a fixed price is always $75,000 for the deployment and base price. And we provide per host pricing for both commercial support and fully managed OpenStack so that the budget can be planned predictably if per host pricing is more predictable compared to what VMware is doing, for example, with their per PLU pricing. So let's not consider a basic test scenario where we're going to compare how, when does it make sense to run a private cloud infrastructure along with using a public cloud infrastructure? So in this cloud scenario, in this cloud scenario, we'll consider that there are 750 BMS with the following hardware resources. So two DCPUs, eight gigabytes of RAM and 10 gigabytes of storage. All of that is running Ubuntu as the operating system. The RAM over subscription ratio is equal to one. And the DCPU over subscription ratio is equal to four, which is not something unusual. As default over subscription ratio for OpenStack is 16. And let's analyze how much is it going to cost to run those BMS on leading public cloud providers compared to how much does it cost to run those BMS on Charmed OpenStack in a private cloud. And let's see when there's a moment when it becomes more effective, cost effective to run a private cloud infrastructure. Because obviously with private cloud infrastructure, you have to make a lot of investment upfront. You have to purchase the hardware. You have to purchase the services. And you have to start worrying about operations as we've just analyzed having a look at the typical IT budget. While with public cloud, you can just spin up all of those and the rest is taken care by public cloud providers. So let's consider Amazon Web Services first. So in order to run this type of a VM, we would need to use T4G large instance type with the following space dose per hour. So that's the annual PCO per VM is around $600. If we use Microsoft Azure Instance, any instance type that would fit those requirements would be D2A for D4, which again is available at a very similar price. This includes the yearly discount based on the official pricing provided by Microsoft. So it's again around $600 or 580. And when using Google Cloud Platform, instead, again, the numbers are very similar. So as you can see, those numbers do not differ too much when using leading public cloud providers because they have to keep their prices very similar so that in order to be competitive to each other. And it also explains what I was presenting on one of the previous slides so that in the beginning, organizations usually just cooperate with a number of public cloud providers to negotiate better prices because they're very close. But now let's have a look on how do those numbers look like when using a private cloud infrastructure based on charmed open stack. So in order to satisfy those requirements that were presented before, we would need to run a cloud consisting of 12 nodes, which is a typical deployment that we do here at Kameleco. And we usually do not go beyond those numbers. 12 nodes is a minimum open stack deployment. A hardware that you would need to invest in to spin up your private cloud infrastructure based on our reference architecture for open stack. And again, this is the cheapest price available from one of the vendors presented before is around 300 of thousands of dollars. So this is an investment that you have to make, your CAPEX codes. And delivery codes is also something that you have to invest upfront, but then you get your private cloud infrastructure up and running. And there are two charges that you would need to pay on annual basis if you want to get a service similar to what you receive from one of your leading public cloud providers. So there is a support code which would be $18,000 per year for those 12 nodes. And there is a fully managed code that is $51,300 per year for those 12 nodes, which means Kameleco would take care of the entire maintenance of your challenge open stack cloud. So that we would monitor the cloud, we would maintain it, we would react on AME escalations, we would resolve incidents, resolve problems, and basically manage the cloud on behalf of you. And now we have a look at the numbers, the initial CAPEX per VM. So this is an investment that you have to make at the beginning is around $500 per VM. But then the annual TCO per VM is below $100, which is much less compared to what public cloud providers offer. If we have a look on those numbers from three year point of view, it becomes evident that after a year, it makes much more sense to run a private cloud infrastructure based on challenge open stack instead of using your leading public cloud providers. It also means that if you're just about to run a smaller number of VMs or if you're not running them 24 per seven, you're just running them on demand. It makes more sense for you to use public cloud infrastructure instead of building a private cloud. So at the end of the day, it's just a trade-up and you have to make those calculations very carefully based on your needs. And the multi-cloud scenario that I described before with using public cloud infrastructure and private cloud infrastructure at the same time and making decisions where to run workloads based on the numbers, based on the cost, based on the economical aspect, is where most of organizations are heading right now. And one final point to make is that again, getting back to this invoice from one of the leading public cloud providers do not forget that what's not included in all of those calculations are additional charges that they apply if you consume a bandwidth, you're getting charged for that. If you consume storage, you're getting charged. If you use services as load balancers, you're getting charged for that. So as I said at the beginning of this presentation, public clouds usually charge for everything. So this is something that's very hard to include but we have to stick to some numbers to be able to provide those estimations. So that's mostly it with regards to this presentation. I hope you enjoyed it. I would like to thank you very much for your attention. There is going to be some time for Q&A right now. And I'd like to invite you for another presentation that I'm going to host just after this one, which is about Microstack and OpenStack on Rails solution. So I would be more than happy to answer any questions that they may have right now. Thank you very much.