 Okay, so I'm Maxime Autran, I'm the product manager for the public cloud offering of OVH, which is based on OpenStack. We provide Swift and Nova as a service, and I'm going to share with you some of the insight and some of the choice we made to make this product easier, especially for most of our prospects and customers that do not know anything about OpenStack and sometimes do not know anything about the cloud in general. For some reasons, I will focus on the VMs on our Nova offering. We also have a lot to say about Swift, but I will not cover that today. So basically, to give you some insight, we launched the offer a bit more than a year ago. We now have more than 100,000 VMs running, commercialized on this offer. And we have a large variety of customers, and that's where I wanted to start the presentation. When we speak about offering OpenStack to the masses, we think, oh, that's a perfect product for a specific persona, which is the DevOps, because OpenStack allowing to spend new machines in seconds is totally controllable through an IPI, and therefore is really a perfect solution for customers that do infrastructure as code and want the infrastructure to be totally flexible. And that's right. When we discussed about launching this new offering internally, OpenStack was a perfect choice for it. It was just maturing at that time, being mature at that time. We saw a lot of implementation, and we decided to go with this solution. But even internally, we discovered that most of our colleagues did not get the full added value of offering the solution based on OpenStack and exposing the OpenStack API. So we waited a little bit, and we designed and marketed a solution around the different persona we saw in our current customer base at that time. And we went back from the use cases to adapt our public cloud offering. So this is the four different persona we decided to work on. So I just spoke about the DevOps, but we also discovered that the needs for the other were kind of different. For example, we were originally a bare metal provider for infrastructure, and we have a lot of cease and mean profiles amongst our customers. And the priority for that persona is actually high availability. It's also the performance. And at the end, it measures, for example, if the solution is good, checking the uptime of a machine. So we had to work a lot on that point. This need was also shared by another persona, which we called the newbie. So basically, it's the customers that wanted an easy way to spawn sometimes their first server ever. The first time they would become a system administrator, and they wanted to spawn it quickly and do basic operations through an easy-to-use user interface, a graphical user interface. And finally, we had a lot of requests coming from project manager or business unit manager from the company we provide infrastructures to. And their needs were about giving more freedom to their development teams for staging and development. And also, they wanted to be able to get predictable costs. That was a great concern for us. So this is an exercise, of course, I invite you to do if you provide a commercial solution. But even if you are in charge of providing infrastructure internally, do not forget to map your customers, and you will maybe discover that you've got different types of customers, and you can categorize them using personas. There is actually a persona working group within the OpenStack community. I had the chance to attend a few of the meetings in the previous OpenStack summit, and I invite you to join them or at least to read through their work on the OpenStack QX Wiki. One of the key differences between the different persona you saw before is, of course, the famous pet versus cattle approach. So we historically have a lot of customers using bare metal servers, VPSCs, and what we call private cloud internally. VPSCs and private cloud were solutions we have been providing for years, and they used VMware solutions. So the key message for those customers were high availability and redundancy of their data. And when we discussed, we had some focus group with them about the upcoming public cloud based on OpenStack, their main concern was even sometimes about the keyword instance, because that terminology was against their value. They wanted servers that would stay during a long time and never get down actually. So we worked a lot on high availability, and we decided, for example, to only launch commercially the product when we have a tested live migration working well, distributed storage using SAF with triple replication, that's the default type of storage you would get from us. And for the customers that were already in a cattle mindset, we also offer an alternative based on local SSD based instance storage for better performance. So each time we are about to improve the product, we always think about our different persona, and we may offer different kind of functionality or service. We also built a large catalog with huge instances. This is a bit against the cattle and the cloud approach, but we had a lot of customers asking for it, because, for example, we offer instances up to 32 cores, up to 240 gigs of RAM, and this is because we see a lot of customers coming from bare metal servers to the public cloud offering, but not changing really the way they manage their servers at first. So they come essentially for features like snapshots, but they do not use the total flexibility they could get from the public cloud at the beginning. Some have workloads that rely also on constant resources, and they were afraid because they tested some other public clouds where the performance could vary over time because of the noisy neighborhood and stuff. So again, we decided to have a quite drastic approach with absolutely no overcommit on our offering. So we communicate clearly about the actual resources you would get when you spawn a server. The last trick we did, that's maybe an idea for some of you, to ensure total vertical scalability, because we have a lot of customers that are still adding and removing resources in a vertical way, so adding, for example, RAM to a server and decreasing the RAM to a server. We offered all the flavors with the same disk size, 50 gig. This way, customers can easily increase and decrease the CPU and the RAM without reinstalling the servers and keeping their IP, because, again, they are not in a cattle approach. Each server comes with an active IPv4. We do not offer flexible IP yet. And each IPv4 is attached to a specific server. We also offer what we call failover IPs, that's an historic offering at OVH. You could move from a server to another and also to other products at OVH that are not controlled by OpenStack. So that people can create an hybrid cloud and move IP from other type of products to our OpenStack cloud. There is some specific adaptation we made also hearing the use case of our customers. For example, our IP are geolocalized. That's interesting for SEO purpose and it can sound really conservative, but that's something our customers wanted to. We have plans to offer floating IPs. We have plans to offer load balancing as a service directly integrated in OpenStack. And after that, offering also it as a service because we see more and more customers starting with a traditional approach and now wanted to benefit from the cloud flexibility and orchestration and automation. So this is what our UI looks like. It's really simplified. We also offer horizon as a service for those that are used to horizon. But we made this UI for a few reasons to simplify the use case. And one of the reasons when we early tested the product showing horizon to our customers is that they were completely lost with the fact that OpenStack is by default designed region by region. So for example, in horizon you have to choose a specific region you want to work in. And that's really not the mindset the customers add in mind because for specific projects, they would use two server in a region and another server in a second region, for example. So the web view you see when you connect to our cloud, show all the resources of the tenant across different regions. All the instances, volumes, IPs, et cetera. I made a really small recording, I hope it will be perfect, where you could see what the product looks like. So for example, if you had a cylinder volume, just click add a volume. You choose the size of the volume and it then appears in your infrastructure and you could just drag and drop it to one of your servers. So again, discussing with CIS admins, we just put in a web view what they would draw on a sheet of paper so that they are really keen with this web user interface. As you can see, there are other small tricks we did. I don't know, I think it's not readable, but at the top bottom of the page, you've got a notification because the server just finished launching. And you get the actual line you would copy and paste to your terminal to connect through SSH to your server. This is really something that makes the product really easy to use for customers that are not used to using this kind of product. So actually, the server is being started. So the volume is being added, you just take it and drop it to the server you want it to be attached to. And behind the scene, it would restart the machine also. Everything you would do in the common line interface is done automatically in one click here in the UX. Going further with the region limitation of OpenStack, we had exactly the same request from customers saying they wanted to create a private network through the different region of the OpenStack at OVH. So we came from the native and we are totally compatible with the native way to create private networks in OpenStack. So this is, for example, two different VMs linked in a private network. A second private network linking to other VMs, for example, in the same region. And we leverage OVH technology that makes L2 layer networks across our data centers. And we just link the private networks that share the same VLAN ID across regions so that our customers can actually create VLANs throughout the world through the different data centers from OVH. It is not closed to OVH data centers because customers could also make what we call a direct connecting from their own data center on premise or from other providers linking to their private network to the VRack. And you can also add other types of products such as bare metal servers or VMware private cloud that are also products provided by OVH. And this is valid in our different data centers. Coming back to a really simple problem, when we launched the product, we had a great success and we had dozens of calls, literally dozens of calls every day because of a specific choice that we made. Historically at OVH, when you would spawn a bare metal server, you would receive a root password directly by email. We considered it was not good enough to, it was not good to do it with a new product and with a public cloud. So we decided to make the SSH key usage mandatory. And people just were not able to create SSH key. So we included directly in the tutorial when you create a server, a small tutorial explaining how to create a key pair in Windows, in Linux, in macOS, just a four line tutorial so that customers can add SSH key within OpenStack and adding it to their server. So I talk about features, I talk about chewiks, but we also made choices around the billing policy. Because the main concern we got from customers trying or hearing about public cloud at other providers were about the billing. They were afraid not to be able to control their costs and not to say they were afraid just to pay a lot more than they used to using bare metal servers. So we made a few choices that were integrated in the business models that we decided to launch. The first one, it's a huge one, is that we decided to make unmetered traffic. So you would only pay the resources based on the early price or the monthly price of an instance, and you wouldn't pay anything more, whatever the outgoing or ongoing traffic is. We also chose to make a single bill, that's what most providers do. And we made a bill by Tenenter Project. So I spoke a bit earlier about the project manager persona. And this was really something that they wanted to have and they wanted to be able to do easily. Is to get the actual cost usage for each of their business projects. So we just told them, okay, create a tenant bar project. We're a technical tenant project within the OVH user interface. And each project will get a bill. Of course, we provide a credit card, of course, we provide PayPal to pay. But we also had a lot of corporations or administration wanted to pay using other ways, such as check or a bank transfer. And we offered them the possibility to top up some credits and then use the credit to pay the bills automatically. A native feature, also included, it's very basic, but it answers the need from the customer is the ability to define a certain level and answer the prediction of what you will use this month goes above this trigger you would receive an email. And finally, for the most conservative customers, we also decided to offer what we call the monthly plan. So basically, you can commit to each server and say, okay, I commit for this server for the month. And you get a 50% rebate and you pay immediately as the monthly price of that server. That's also helps us predicting the supplies. Because we know that if the customers commit for the month, there is a huge chance they will still use the servers the next month. So that's basically what we did to improve the onboarding. But I also wanted to share with you, to be totally transparent, the ways that we consider we are not perfect concerning our public cloud offering. And the first fail is actually the product name. Because when we, especially we were from France and when we launched the product, we launched it in France at the beginning. Now we've found worldwide. In France, the term cloud is commonly considered as a synonym for Dropbox or object storage. And we launched at the same time object storage using Swift and also cloud servers. And we had a lot of efforts to explain to the customers what OVH public cloud server means. OVH, so that you know as a large catalog of infrastructure and adding those public cloud servers essentially made the offer more difficult to read. We also discovered that the virtual machine market is really crudded. And it's crudded mainly by over committed VPSs. And it's again very difficult to differentiate in the market and make our differences clear, such as the no over commit policy. We did not manage to find a way to explain that really clearly too. We also, I think, did a mistake offering at the same time object storage and VMs servers because the market was not ready to understand the key differences between, for example, sender volumes and object storage. Even I think in the room everybody is really aware of the difference. It was not the case of our prospects and customers. And even in the interface you just saw earlier, for example in the billing you would get a single bill for object storage and for servers and that's a choice we should not have made. Because we discovered now one year later that the use case are totally different and the customer are totally different. So it makes sense to integrate, for example, Nova and Cinder because you would never use Cinder volumes without a Nova instance. But we have a lot of customer using only Swift or using only Nova. So we may split those two products and market them differently in the future. Another point where we are far from perfect is our management of images. So like all other products at OVH we will provide pre-installed OACs, about 15 different flavors of Linux plus Windows and free BSD. But we had to comply with OpenStack because we are OpenStack powered. We are one of the ones in the interrupt challenge yesterday. So it's really important for us and for our customers to stay totally compliant with OpenStack. But at the same time, we had to design the screens like that with a dash deprecated, etc. Because we do not handle well the deprecation of images. We made small acts to include, for example, Windows listening within the pricing of our servers. So you would actually get the standard flavor and the flavor dash windows that we would build differently. And that would include the Microsoft Windows license. So a lot of small acts that we made and that we still have to improve because I find this screen not really readable, for example. And we are just short on stuff also to have this OACs up to date on a daily basis. We also have work to include features to import and export images from other public cloud providers, also from VMware and stuff. So all this is natively offered within horizon and within the API. But our customers find it not that easy to use because they have to upload it somewhere, for example, at first, because their connection is not a performance enough. So we have to include those import and export services within our offering in the upcoming months. And the last thing that we still have to do a lot of work on is pre-installed software stack. So currently what we propose is just type your user data, script here, but we want to include a catalog of scripts there. And finally, one of the top requests we have from our customers is having a clearer and more accessible documentation. So today, most of the time we refer to the official open stack documentation, which is not always up to date and which is more targeted to develop since these admin operators mainly. So we make a huge effort to contribute to that documentation, but also to write a more comprehensive documentation targeting to our early cloud users. So we started working on webinars. We are working currently on tutorials. And we still have a lot of effort to do at that point. And finally, for example, during this summit we were a sponsor of the OpenStack Academy and we want to learn from that to replicate that in the event that we organize ourselves. So basically that's all I had. I'm available to take some questions. Maybe some of you are also public cloud providers. Maybe some of you are providing infrastructures to other teams within your organization. So do not hesitate to use the mic if you have any questions for us. So any questions? Perfect. Thank you.