 Hello, everybody. Good morning, everybody. So we're ready to go. So thank you for coming this early. I hope everybody has their own coffees and ready to learn a little bit about the Battle of the Distros, which one is the better for my cloud. My name is Edgar Magana. I'm a principal engineer for Cisco. With me, my friend and ex-co-worker, Robert Starmer. Yes. So my name is Robert Starmer. I was also a principal engineer at Cisco. I am now a consultant for one cloud, working with Cisco fairly closely on a number of these sorts of engagements. So we just have 35 minutes, 40 minutes for this session. And I'm pretty sure there will be a lot of questions. I hope so. So Robert and myself will be available after the session outside. Feel free to, you know, if you don't catch us, we can talk later, or send emails, et cetera. So we're going to talk about the battle. You came here, and you see a lot of vendors. And the battle that I wish I could talk about it is this kind of battle, because this kind of things I really like it. Unfortunately, it's not these kind of battles. We're going to talk about OpenStack. We're going to talk about a few companies, vendors, that are just being created around this beautiful ecosystem. Thank you to the power of the cloud. Thank you to the power of OpenStack. So when we're talking about vendors, it's kind of like a very complicated topic. This is what I think it's very important for you to know who I am. So I'm part of the community since 2011, at the Santa Clara Summit. I'm a neutron core developer since 2012. I'm still like it, love it. I've been working with distribution science. They were great at it. Why? Because I always wanted to run things in the real world. DevStack is great, but I wanted something else. And Robert and myself, we started working on how we can actually automate what kind of orchestration tools we found to make it simple for us, our development, our testing, and for you, the users, to make it to production. So I do not represent any specific vendor or company. Hopefully, that's going to be a very, very subjective topic. And one of the good things my current employer, Cisco, doesn't offer any distributions. So if you ever heard about Cisco and Stackistar, it's not real at distributions. And we were going to talk about what is real at distribution. So my goal here is to help you to go to production, to help you to have the best choice for your vendor, or there are two other options. Do it by yourself or just give it a way to somebody else. So we have vendors for that as well. So my passion is very simple. It's been open-stack science for years. So with that, what are the goals of this session? Well, bummer, but I will not tell you which distribution product to use. I'm not going to do your homework. That's going to be yours. So to have a better idea of a few available open-stack distributions and products. So there is through you to understand the factors and be aware of, when selecting a specific vendor solution, what do you need to know? So I'm going to give you some weapons to use against all those sales guys that will be calling you because they scanned your batch already. They're going to be sending you emails and they're going to tell you our solution, our distribution, our product is the best way. So then you're going to start asking questions. And let's see what is their reaction, face to face. And I want to wake you up just in case you're still a little bit sleepy. So let's try to make it interactive. So I'm going to go as fast as possible without mumbling, hopefully. Just to have time for questions, right? So the very first thing is to understand what is really a distribution versus a product. What is the difference? And for that, I will ask my friend Robert to explain a little bit with that. Yeah, and so the reason that Edgar actually asked me to come up here is that about three years ago, when we first started looking at this space, we ran into the same problem I think all of you guys have, which is you found that there were great instructions for how to install the specific pieces of open-stack, do a lot of this stuff manually. There certainly was DevStack even at the time. And we were looking at how you took that simple set of tools and the basic configuration that you did manually and turned that into something that you could actually use and repeat, whether it was, in our case, a test sort of an environment or in the customers that we were working with in their environments and something that they actually wanted to turn into production. And we found that there were a lot of things that were being called distributions at the time even, mostly it was based on the operating system vendor's stacks, so their tool set to actually get an operating system installed and then taking that to actually get something like open-stack installed. Certainly there was Chef-based and then some initial puppet-based work that had gone into building the automation of the different individual pieces and those pieces became distributions. So Red Hat had some initial components along with the Fedora project. Certainly there was a lot of work that had come out of canonicals environment. These were the distribution class systems. So there was a way to get something up and running but there wasn't really much beyond the fact that the pieces existed. Kind of like if you deploy Apache with a Linux distribution, you get a web server but not a whole lot else. You still have to do the rest of the automation, the rest of the installation of the services. That's the distribution space. Then there were the vendors that were coming out at the time that said, look, we've actually got a product. We've got something that you can either pay us for support for or actually even buy and that's product from the all software perspective to even entirely bundled hardware systems. And looking at the two and looking at the difference between the two is I think one of the key things that Edgar and I kept running into. Well, which do we go? Do we actually get a product vendor in to actually start looking at how do we get support from them directly for our individual changes that we needed for the development that we were doing. So the work that Edgar was starting up on Neutron, for example, versus the sorts of things that we needed to help our internal customers that really wanted to sit on top of the cloud start using, right? So the product versus distribution was sort of a question of, do I need somebody to just come in here and help me do something and I don't really care about the internals or do I need enough flexibility from sort of a distribution and a distribution plus deployment automation tool set to actually potentially morph the back end a little bit and tweak the exact sorts of systems and components that I wanted to use. So that was I think something that was very important. And when you guys are looking at this, I think that's one of the key things that we wanted you to take away from this as well is that the product systems are great if you're just trying to get to production and have somebody there to effectively hold your hand through the process or even hold your hand into your production environment. Whereas the distribution side of things is definitely something that you can look at if you're really going to have to tweak some of the back ends. Maybe you're building your own product that fits into the OpenStack community or OpenStack ecosystem. So that's really I think the key that we wanted to get across, right? Thank you, perfect. So without, now we know that in the bottom line, the distribution will give you a lot of flexibility and the products will give you something that is finally done, that you switch it on, should be working with some kind of customization that is being created by someone else that is not you, that is not your IT. So we will investigate a little bit more about that. So let's go for the questions. What are the right questions to ask, right? So the very first one that you already asked and answered was I want to create a cloud management system which software should I use and you all say OpenStack, thank you. Can I get to listen? This is why you're here. If not, you are in the wrong conference. So right after that, you should start asking the following factors. The order, it could change. I like to start talking one of the most expensive ones which is actually the hardware and the implications with the operating system hypervisors that you will put together. So this is one of the first decisions to make. Then you need to talk about the reference architecture, right? Is this solution product gonna give me high availability? This is for production, right? You need to have it. What is the process to upgrade it as you can see the software is going too fast. So I will dip dive each one of them. So let's just start with the hardware. So when you go to most of the products, you need to start thinking about what are the hardware implications? One of the things that we have in mind as an OpenStack developers is we're creating some kind of software that it will not let you fall into a vendor locking. So this is very important that you will have the flexibility to choose the hardware that you wanna use. However, some of them did not. They are fully tested and certified for a specific hardware. That could be good for you because you don't want to run into hardware failures, on capability of drivers and things like that. So you think about it, you need to start asking those questions because this is very expensive and you want to have the flexibility to choose what you wanna use, right? Other thing that is very important is nested virtual decision. This got tied to the reference architecture. So by now I hope everybody has in their minds more or less how is the default proposed reference architecture from the OpenStack team. We normally have the concept of these controller, compute nodes, network nodes, et cetera, right? So there are certain components that they don't really need to run environmental. So think about it when you talk to one of these vendors, ask about these, try to see the reactions. Some of them they don't even know. So I just gonna let it there. I'm not gonna say specific which one of them, but you can ask me later after the room. Certifications is good, it's good to have. It doesn't guarantee that you will not run into failures. It's just attack, to be honest. It's just attack, put it for another vendor in a different vendors to create a partnership and to make business together. But doesn't mean that actually it's not gonna run into any failure. But it does mean that a set or certified test were running into that hardware. So think about it, which kind of test? Mostly 50% of them are tested by one of those specific vendors and the other test are actually the test that the OpenStack community created. So that is great. Robert, there's something that I'm missing. No, I think this one I think you've covered pretty well. Yeah, and this is very important guys. I mean, hardware and the parent system, why? Why the parent system? Because you may choose a Linux flavor, but the Linux flavor will have another complications. You have also ESXi, you have Hyper-B. So all those cost money and support and start making demands. So I want you to start thinking how much is gonna cost you to the data center because it's actually the homework that you will be doing. I'm pretty sure most of the people attending these is because they're having their demands to build these. They need to report back to somebody else what's going to be the process. I guess the one thing I would comment on that though is this connection between the hardware and the operating system and then the OpenStack middleware that sits on top is actually important, especially if you're looking at specifically the sort of a distribution class system. So something that might actually even be at the product level where you actually have a company that's going to support the entire deployment of the system on top of the hardware. It just being x86 hardware, it doesn't necessarily mean that the hardware vendor can support the platform or the product of OpenStack or version of OpenStack that acts more like a product that sits on top of it. So it is actually probably good to make sure that when you say, hey, I'm gonna take specific Linux distribution or basically a productized version of a Linux distribution with the OpenStack pieces on top and I want to run it on what looks like generic x86 hardware, make sure that there isn't an interaction on the storage driver front, on the network interface driver front. These are I think important questions to ask at the hardware level. So let's move on, let's go to the next one, reference architecture, high availability. You need to start asking what is the HE model? And the HE model is for many things, right? For the hardware itself, right? Your core switches should have some redundancy, your actually OpenStack components should have some redundancy. And unfortunately for you, us, developers, we have different silos for each one of these components, Nova Neutron Sider and the HE models are a little bit different between them. So be sure you actually have somebody behind you helping you to understand all these models or even better, try to understand all these models by yourself and trying to make the reference HE architecture very compatible with what you in your IT operations team are familiar with. It's very disruptive for a company to move into open source, that's a big change for some of you. Now if you are asking them to actually change the HE model it's gonna be even more disruptive and I'm pretty sure not, you're not gonna have very IT guys happy. So this is very important. Try to make all these HE components in a way that they have exactly the same model, a very similar model, even that is not 100% possible because it's going to be very easy to handle any troubleshooting. I'm aware of some companies, some products out there that actually have a very good crazy HE model. The question that I would have for them is that model easy to troubleshoot, easy to debook. Think about it, when you have every single server in your distribution as a controller, the monologue that you may have, so just be aware of the implication of that HE model. The typical active active, with even three controllers, it's one of the most popular I will say and you can also try to ask the people who is already running in production, that is good enough. So my only comment on the high availability side of things is that it's probably interesting to look at high availability within a single region or a single system that gets deployed. So basically the physical hardware plus the control plan that sits on top of it. And we've done a lot of work together in the past looking at both active standby models. That was the first model. We actually helped also build out a version of an installation tool set for an active active active control plan environment. One of the interesting things I'm seeing more people look at as well is multi-region high availability. So if the applications that sit on top can actually deal with failure, if they're built sort of in a web scale model, then you can actually look at regional controllers. So you can actually get rid of the high availability component at the control level and assume that the application can actually deal with failure at the single system level. So it's another area to look at as you're deciding what the right process is and pathway is for your actual particular deployment. And remember, I mean, most of the distributions will let you design the HM model with your team versus the products that they will tell you this is the model and that's it. Because what? Because it's a product. So the next one is the code upgrades and scalability. I mean, this is critical. I mean, we have nine releases of OpenStack. We keep releasing a new version every six months. I'm so happy to have this model. So this is a very simple question. Will your solution be able to be upgraded to the next version of OpenStack every six months? Yes or no? What is gonna be the thing that is gonna take me to do that? My cloud is gonna be down or it's gonna be keep running 24 seven. So why is so important to keep upgrading your OpenStack distribution? Because I think about it. I mean, the amount of code, bug fixing and new features that is added every six months is huge. The community, you say it around, right? 4500 attendees to this summit. It's incredible. For the people who is gonna be hanging around on this floor, there will be a lot of the science sessions and you will see how many developers will be in for each one of these components. So don't lose that advantage. And try to go for that kind of solution that is up to date. I cannot imagine that you're thinking about deploying a cloud in the next three months with something grisly, older, even a banner. I would try to encourage you to go as moving forward as high as possible, which we even internally try to enhance the software to make it easy to upgrade. So if you get in the past, it's gonna be harder for you to move to the future. But if you're already in the present or even looking ahead, it's gonna be simpler. So I really encourage you to ask that question. So one of the experiments that I did was to surf in the distributions, products, websites, and very few of them tell you exactly which open stack distribution they are running, which release, sorry. And that's amazing. When I start digging a little bit more, there were so many rounds, rounds, rounds of the things that they didn't really clearly tell me what was the answer. So be very straightforward and ask how much it's gonna cost to do that upgrade. And the second part is the scalability. Do not get locked in one cluster cloud and that's it. Some of them they do it like that and they claim that in order to make a scalability, you can actually create a federate cloud and make some connection and some crazy stuff. Be sure that you have the ability to start adding computers, even controllers, et cetera that you think that you will scale up in the next 12 months or 16 months, et cetera. One other factor is zones. So probably you're familiar with this term in the computer area that you can create your own zones and you can actually scale up VMs on those zones. So be able to create multiple zones. This is a very good feature. I will encourage you to actually have a solution that will lead you to create them zones. So this you have another questions to us today, to the vendors. So again, I'd add another comment about this. When you think about upgrades, I think this actually maps pretty well also with the way you think about high availability. I've worked with a number of folks that have actually tried to upgrade systems that are single system environments. And while it's getting better and better, some of the NOVA comments about how the NOVA team is dealing with database upgrades and migrations and even interactions between the different components of the NOVA system, when you start thinking about managing those upgrades, if you can build a high availability system that actually is effectively two separate environments, unless again, a product company might have a better way of actually managing that because they've built some of their own effectively specialization on the back end to support those upgrades. If you actually think about your high availability environment as two separate systems and can build out two separate systems, you actually have a way to basically do sort of a flip-flop upgrade where you migrate all of your users to one system, upgrade the other, and then migrate back. It's just one model to think about when you're looking at how can you leverage, especially if you decide to go the distribution route where maybe you have a little bit more ownership of the system that you're deploying, how do you actually leverage these environments? So just get another thing to keep in the back of your mind. So the next one is one of my favorites because so many people did just forget about the licensing and the licensing is, it's a little bit complicated because you need to start asking, are you gonna be paying for server, per socket, per subscription base, and then you're gonna be paying for the hardware, you're gonna be paying for the distribution itself, for the support. What about the grades? Are you gonna be paying for the grades? They may ask you to pay for that. Why you have to pay for that with something that we are trying to make it as simple as possible. So do not fall into those traps. You actually should be having a solution that not gonna be adding pennies for every single thing that you wanna run. This is very important. Installation deployment, when you have a product, it should be very simple to start, it should be very straightforward. However, you need to be sure that it's not gonna be any added costs. With the distribution, you have more flexibility in that area, so you can manage more the costs. But one of the things that you can have a problem with the distribution is that you start pulling many things from different places. Maybe you're calling in more than two, three vendors and all of them, they wanna make money, right? So be sure that at the end of the day, what you're still doing all your math don't end up paying more. Some of the distributions claim to have a lot of compatibility with all the components through what they call the enterprise version, right? So just think about it, how much more it's gonna be for each one of these enterprise licenses, right? And if you are really looking into a distribution, in this case, try to explore the alternatives, try to explore the presence and sense of the flavors that will not cause you money, right? Try to ask this question, let's say for instance, to the real guys, to the suicide guys, what is really the difference between what is called RHOS versus the RDO? Right, that's a very important question, because you can just go leave with the RDO, maybe running in CentOS or something else, maybe you're good enough, but maybe you wanna have all the supports that RHEL is gonna guarantee you and you wanna go that. I'm not telling you which one to use, again, I'm telling you the factors that you need to ask in order to make a decision. Another very important thing, I mean, creating a cloud, a new cloud with OpenStack, it's a very amazing trip. Make sure you do it in phases, make sure you start with your POC, make sure you go to your prep productions racks, make sure that you have all these phases in place and make sure that it's not gonna cost you more money than what you were expected to have, right? So the idea is to go to production, you wanna test your product, so I just wanna have for free, or I just don't want to pay more that is gonna cost me at the end of the day, again, just ask for those kind of questions. If there is some extra components that you wanna add and it's flexible enough to add more components, what's gonna be the support model for those ones? And in a little bit, we're gonna be talking about those support models. Yeah, so the only other thing I would say in terms of considering cost models, it's not just the software that you have to consider. If you're looking at the cost of deploying a system, you can look at the hardware, hardware cost and licensing and support costs. You can look at the operating system, licensing and support costs. Again, if you're looking at the product model for open stack deployment, that may actually include all of that wrapped together, right? So it might actually include the physical hardware plant, the software that's being run there, the management software that they may add from a product perspective to make it easier to manage this. And I think one of the key things that's going to drive the decision making here is, are you looking to operate a cloud, are you looking to build and develop something within that cloud space? That's gonna be a large factor in driving what the right potential distribution or platform is to actually go forward with. And with that we move into the next one. I love this one, plugins and drivers, why? Because we create open stack such a way that is fully compatible with N number of vendors and your solution, your distribution, your product should be compatible with them as well. So the question that you should ask is, how flexible is the solution if I want to use a plugin X for Neutron and plugin Y for Nova? Or any kind of combination that you wanna use because it's the solution that you have in mind. Think about these, some of the solutions are not compatible or tested or even talking between different kind of vendors. For good or for bad, you need to be aware of those things and you need to be asking when is that going to be possible? Again, open stack is very flexible, right? Don't lose that flexibility. So let me select any storage backend system. Let me select my messenger system. Let me select the kind of database that they already have in IT operation. What if you have something that you're really running in your system as a vendor, but in your IT team are very familiar with something. Don't create a crazy environment just because the vendors are not letting you do it. So we're building something to be flexible. Don't lose that flexibility. And very important, I don't know. I run the POC, I found out a bunch of bugs because of the messenger system. So I changed my mind and I wanna change to the other messenger system. Is that possible? How much is gonna be? How much in time, processes, resources, et cetera. So think about it that. There are actually plenty of drivers plugins around there. I found Mirantos recently post a very nice resource tool to actually find out all of them. So you go to that link, salistic.com, drive log. You will see a very nice web page that you can actually select the specific OpenStack component. And all the plugins drivers available there. It's very cool and actually tells you the testing part and a bunch of information that you may not aware. So I encourage you to look at this website. Recently, today, actually two days ago, it was the build, the OpenStack marketplace. This is a great place to actually find also drivers, what is available there. One of the things that is very, very important, if you are going to use one of these plugins, because you wanna talk to that company, make sure that that code is upstream. Do not select, and as my advice, do not select a product which their specific driver plugin is not pushed upstream. It's very important because there is a process, there is co-quality, there are some testings that needs to be passed. And there is a reason why you have to ask that person why you're plugging, why you're driving, why you're pieces over that you're trying to put with OpenStack is not pushed upstream. Everything should be pushed upstream. You should ask for those kind of things. Somebody's not pushing upstream. You can actually go to the review.openstack.org and find out where are the comments of the developers and you will find out exactly the truth. So I encourage you to go there. So this is very critical because OpenStack is all about this. And if you don't have the full visibility, you may lose very cool features that you want to offer to your users to your IT operations guy. So another way to think about this as well is especially if you have a hardware platform that you have to use. So maybe you have a corporate set of requirements that's driving a specific set of tools. Obviously each of those individual vendors potentially on the storage array side of things, network services side of things, something along those lines are gonna have different sets of capabilities. It's probably important to consider what those capabilities are, what out of those platforms it is that you're looking to hopefully incorporate into the OpenStack environment and make sure that the vendor is willing to actually support the whole path of either getting, like Edgar was saying, getting the driver enabled for that particular set of features, pushing that code back upstream into the community so that everybody can benefit from the enablement of that capability, at least seeing how somebody else might actually implement the interaction. For example, on a storage path, how do you actually create a volume and delete a volume, right? A lot of that work has gone into the community and is leverageable by everybody. But we're also, it's also, I think, important to look at how it goes the other way, right? How can you actually make sure that the support exists for those low-level components that you actually either have to or might want to use in your environment? So let's go to the next one. Customer support and documentation. A very important question to ask. What is gonna be the customer support model? Is really the support 24, 7, 365? So you need to investigate about that. I already asked you to ask how much it's gonna cost to have these kind of investments. Because believe me, you will have issues. No matter what, you will have issues. It could be a simple configuration issue. It could be a bug that you actually found in your testing or ready to go to production. So be sure that the support that you have is not just a guide answering the phone call, say, yeah, somebody's gonna take a look at that. It has to be forwarder than that. And there should be some action and reaction plans. You go there and say, okay, you're gonna take your product, I'm gonna go with your distribution. What is your reaction plan? If I get a problem Friday night, 6 p.m., 8 p.m., Saturday, 2 a.m. What's gonna be the reaction plan? Exactly what is the person who's gonna be in church who's gonna be pulling the locks? And now where the locks are gonna be located? You need to have the plan to say, okay, there was a failure. The failure is on the red flag, so the cloud is almost down. And a bunch of people is waking up and is trying to pull the locks from every, all different places. Is that the right plan? No, it's not. There should be a very smooth plan to collect the locks, to be in the same place, to not be interrupted with the operation of the cloud, and let the expert to analyze the problem. When you go to installation deployment, be sure that you can do it by yourself. Be sure that whether it is your decision, you have enough support and documentation to do it by yourself, to replicate whatever they are doing. For us, it's very simple. I mean, sometimes I just been deploying some of the dishes or whatever I can found. And after doing two, three times, it's just go natural. And then I skip certain steps, but that shouldn't be the case for you. You should be able to reproduce whatever any other person is putting in your hardware. It's very important to be aware of the code. This is what I actually put this graph here. This is just pulled from the statistics again. Because, again, I'm not in favor of any company, but what I'm in favor of is the people that actually is aware of the code. And in this website, you can actually see the contribution by companies and also by people and also by components. So you can actually, if you are very focused and you see that one specific component will give you some troubles, you may wanna go for one of those companies who has people contributing. It doesn't mean that you need to go to the one that is the top contributed. It just, you just wanna be sure that they know what they are doing, that they know the code, that they have some people aware of those changes. On the other hand, as the developers, we like to keep adding code and adding the features, so sometimes we change the tag here. So these graphs could change drastically with the time, so be sure that you know the people behind it, not just the names, not just the tag. About the documentation, I ran into some distributions and product where the documentation was minimal and some others were amazing. I really like reading the documentation from some of them. So I've encouraged you to don't ask for it, try to get it from the website, from whatever they told you to do it, take a look on that and see that is what you're looking for. Yeah, and again, I think from the concept of support, I think there's a question of, are you looking for distribution or platform that is something that you need to support directly? In which case, I think the case of documentation becomes even more important. How do I get the right documentation if I'm actually going to try to support and operate this environment, rather than just build something that we're going to go develop against? I think that's probably one of the key things to think about and especially when you're looking for potentially a partner, so either somebody who's gonna provide a platform or even a distribution partner, is their support operation going to help you operate that cloud for yourself, for your customers directly, right? This is straight to the next one. So we're five minutes away, so I wanna have time for at least one question. So time to deploy and testing, to be sure that you have all the testing tools, all the testing plans in place, ask for their testing plans, create your own testing plans, be sure how long it's gonna take you to deploy the cloud, what are gonna be the factors involving on these deployments? Mostly time constraints. Think about when you create this ecosystem in your cloud and you're pulling different vendors, the more vendors, the longer will take your deployment. Because you need to coordinate different teams from different geographical distributed areas and even with different backgrounds. So I'm not telling you don't do it, I'm just telling you just be aware of those kind of things. And we're almost done, this is the last one of the factors, but one of the things that I wanna say to all of you, may the open start be with you. If not, outsourcing will be with you. And what I wanna say with this is, if after all these, I scare you up, say no way, I'm not gonna invest in that cloud because there are so many things, that's a bad one. You may don't have the resources in terms of money or people to do it. So there are some other companies around in the marketplace that actually can do, can host everything for you. All powered by OpenStack, right? So that's another alternative. Take a look to that, investigate homework. And with that, so this is the website of the marketplace that it was just released two days ago. And with that, thank you. Remember OpenStack C-School, we're hiring people and open to questions, thank you. Hello, yeah. So I'm the OpenStack package maintainer in Debian. And I've take some notes on what you just said. And I have some, okay, I do not agree with all of what you said. Like, we're talking about free software here. And to me, one of the key important things that we have to keep in mind is how can I contribute? We have the culture in OpenStack that we all should upstream everything and that we should share our code, okay? I'm disappointed that the current state of things right now is that it doesn't also happen with distribution and packages. So I think that one of the key things that people should keep in mind is how can I contribute? Is it easy to contribute back to the distribution? And also another point is that currently we have distributions equal vendor equal support. And I think all the slides that you displayed here take that as a fact, okay? That the distribution that is going to provide me the OpenStack deployment system is also going to be the one that is going to provide me support. I like things to change and that things doesn't stay this way. So that I think that one of the key points when you select a distribution is that the person providing support for you is distribution agnostic. And then after you can select the distribution you want. So that the person that provide you support is not married with the distribution. So sorry to interrupt you. So the people behind telling me it's nice for you so we need to move to the next session. So it seems like more like a conversation to add straight questions. So I don't want to close it here. Let's talk outside. Let's take this. But I want to share you've talked to a lot. I think it's actually you've got really good points. And I think the key point you're trying to make is this is community-driven software. It's community-enabled software. While what we were trying to provide everybody with was a view of how you might leverage these tools going into a production environment always consider how you can contribute back, right? I think that was effectively your key point. This is something that only grows and only gets better if people don't just sort of hide it off in a silo in a corner somewhere and say, well, I'll get somebody to support it and I don't have to worry about it anymore, right? I think that's absolutely key. There are going to be people that do need exactly that kind of system. They're looking for a set of tools and they want to move from that set of tools to something next, right? So with that, thank you very much.