 My name is John McWalker, but before I get into my talk in a minute, I wanted to take a minute or two and let the speakers introduce the topics that we'll be talking about later today. So if you're a speaker in this mini-con, raise your hand. So, Tycho. Okay. Tycho, do you want to stand up and just sort of tell everybody what you're going to talk about? Sorry, I didn't know this part would be recorded. I'm going to talk a little bit about AlexD, which is a project that we announced. It's a system containers project for, you know, used with things like OpenStack and other things like that. So, I think gentlemen up there, raise your hand. Oh, there we go. Perfect. Thank you. Yeah, if you're a speaker, go ahead and come on down. So I'm going to be talking about the challenges and solutions to some problems that we had while we were building a containerized architecture at LIFX. And what is your name again? Daniel Hull. Thank you. Any other speakers for today? Come on down and introduce yourselves. That's okay. We'll give you a chance to get later. All right. Thanks. Okay. So, like I said, my name is John Mark Walker. We're going to be talking about hybrid cloud management and in particular what we're doing around the ManageIQ project to address the problem of how do you control all the things? How do you automate across multiple cloud platforms? How do you orchestrate across multiple cloud platforms? And how we're addressing that with ManageIQ. The concepts behind this, well, really this talk is in two parts. The first part is sort of the reason and impetus for why we're doing ManageIQ. And then the second part is what we're doing community-wise to address to create a larger and more dynamic community around ManageIQ. So, there's a technical part and a community focus. But first, let's get along, let's go into who needs management. Management is such a loaded term. Everyone hates word management, at least I do. I don't know about you, but usually it's used in negative connotation. Either it's used to talk about some large, enterprise-y piece of software that nobody likes and hates to administer, or it talks about, you know, management, food chain, and how everyone, you know, dislikes the management they work for. Regardless, the term is kind of overloaded these days. So, on one hand it's needed and necessary, on the other hand, you know, no one likes to use it. So, who needs management? Well, unfortunately, as we go forward, especially when we talk about all the different components that make up the modern data center, the different public clouds, the private cloud platforms, the containers, the virtualization platforms that we all have to use. Unfortunately, that requires something extra above, sitting above that, to be able to bring it all together. Otherwise, you are spending your entire day chasing your tail. And then, you know, everyone likes a good fluffy mascot, so I figured why not a sheep? Because, you know, sheeps need shearing. The sheep has kind of become the default mascot for Managed IQ because there's a story behind that, because one of our features that we like to talk about is called virtual machine fleecing. We talk about virtual machine fleecing as in sitting on the hypervisor and taking all the information out of the guest that's sitting on the hypervisor, and we call that fleecing ergo sheep because fleecing, anyway. So, there you go. I didn't say it was a good story. I just said there was a story. So, when we look at, this is a very bad diagram to describe what I've noticed over the last 15 years I've been involved in open source software of how things follow a certain pattern. And there are two aspects of this pattern. There's the initial technology thing that it's cool that everyone likes and becomes ubiquitous. And then there's the need to bring that thing under control and integrate it into the systems that we all use and enjoy every day and make some sort of, make it something that has clarity that we can all manage and use appropriately. And then the second part of that is the management tools we use to bring these initial disruptors under control, those things also follow the same pattern. And by that, I mean, so when you look at a new technology, let's say, you know, in 1999, 2000, there was the Linux, you know, Linux-based operating systems. They first started to make the headway into data centers. Later on, virtualization started to become a very big thing. These days, we're talking about, you know, Docker and containers. They become this hot new technology that hobbyists, developers, leading edge people, start to play around with and start to use seriously in some way. But they're not, you know, initially, at least, they're not something that you do core work with. Over time, though, they get adopted more widely, a lot of times as part of Skunkworks projects that aren't officially blessed by management, but they make their way inside the data center anyway. Linux and open source in general followed this general pattern for many years. For many years, Linux and other open source tools flew under the radar, as everyone in this room knows. But then they start to proliferate. And over time, they become a problem if you're, say, a CIO type or an administrator who likes to keep things under control. It's a problem for you because you can't control it. These things are under your radar until they're not. And then how do you address them? Chaos and then control. And control is usually when some IT guy says, I need to have a management tool for this thing. So you have the technology that follows that cycle, and then you have the management tool comes in. And for a while, you had the open source technologies that followed this cycle, and then you had proprietary management frameworks that sat on top of them to bring some cohesion to the whole story. But now we're coming to a point where this cycle happened so quickly and with so many pieces of technology, how do you keep up with it all? If you had the old proprietary large behemoth frameworks, you could do that, but recently, it's become even more problematic because just the sheer amounts of technology and the speed at which they flow. So how can you control that with a proprietary management framework? Well, you can't really. And that's where something like Managed IQ comes in. And now we're introducing Managed IQ as an open source manager of managers, and it's going to follow the same cycle. And now we're ending up with a set of management tools that follow the same cycle that was usually reserved for these early stage technologies, where you're looking at OpenStack, you're looking at all the different open source virtualization management platforms, you're looking at things like Managed IQ. These things are starting to follow the same pattern, but they're used to manage other open source components. It's kind of completing the circle. I understand that this diagram really poorly illustrates the concept of trying to get across here. So if you have, if you know any designer friends who could do this much better than I did, please do contact me after the talk. And so why are we doing this open source? Why are we doing an open source management tool? Why is that important to everyone? And the way I like to talk about open source is it's the revenge of the customer. It's the revenge of the end user. Open source is about the end user rising up to the same level as the vendor or developer. And it's this kind of shift that's come about because the freedoms that are granted by open source and free software that allows everyone to sit at the table on equal terms. And this is kind of the biggest shift that's happened in computing over the last 15 years. Just another word on this. It's, this is what makes things like OpenStack, like Linux, the open source virtualization tools that we all know and love, the containerization. It's what makes it all possible and used. That's why we have the need for open source management tools in addition to all the other stuff. So now back to the kind of main topic at hand, hybrid cloud computing. First of all, the question that is obvious is, who needs it, who uses it? There's obviously an interest in it because no one wants to have one platform to rule them all. Everyone has multiple things that they have to use, managed because of whatever decisions have been made in the past that are impossible to remove completely. No one's going to go in Greenfield, remove, rip and replace and have this one thing that everyone uses. People will talk about migration to public clouds, but frankly, no one is going to be using Amazon 100% of the time. No one is going to be using a single OpenStack distribution 100% of the time. No one is going to be using a single version of anything 100% of the time. So therefore, if you're using virtualization and cloud products at all, you're going to be using them in a hybrid environment. Whether you're talking about VMware and the vSphere and public cloud tools or OpenStack or some other virtualization platform, you're going to have to be using them together. You're going to have to build applications that talk to all of them. You're going to have to have administrative tools that speak to all of them. You're going to have to create some sort of coherent interface that users, admins and developers can speak to without too much trouble. And it's a bit problematic. To further continue the questionnaire that is illustrated on this chart, a lot of the issues around clouds and hybrid cloud management, a lot of them are technology problems. They can be solved by technology solutions. Some of them can't. You'll notice that some of the challenges have to do with culture. And I'm sad to say that there is no technology solution for culture problems. But a lot of these things do have some technology solutions at hand. When it comes to management and operational processes, there is a solution to that in the form of better administrative tools that can help you deal with that. Better security models, there are things that you can do to architect better security in your data center across all your platforms. There is no cure for politics. What is it? The eighth layer of networking. And so when you think of cloud, you think of all these different things that come together. Everyone thinks about self-servicing. Everyone thinks about workload management, application deployment, lifecycle management, all these pieces make up a cloud. When you really think of all the different components together, it's impossible to use a single platform to manage them all, at least from a central location, without kind of the manager of managers, without some kind of abstracted framework that sits above it all, that allows you to manage it in one place. So let's think of, from the administrator's point of view, they have several different applications running on several different stacks. How do they address them all? How do they deal with them all? You've got your open stack-based applications and virtual machines over here. You've got your public cloud-based applications and services over there. It's kind of problematic for an admin to have to deal with each one of those individually, and it becomes, frankly, a waste of time. The same can be said for developers or end users. If an end user just wants to pull resources to do part of their job, where do they go to do that? If a developer wants to write an application to do something that is deployed internally at work or wherever they need to do, which platform do they use? How do they actually access it? What kind of service catalog lets them do their job without having to worry about what sits behind that? And let's not forget the fact that I have five logos here. Each of those represents a different API. Each of those represents a different administrative interface, a different dashboard, a different set of workflows. There is no cohesive workflow in this situation. And so hence the need for a cloud manager, hence the need for something that sits between the end user, developer admin, and the set of services you want to use, deploy, manage, et cetera. There is clearly demand for this. There's clearly a need for the ability to abstract one top of an existing set of frameworks. But it's more than just deployment. It's also about how do you delegate which parts are accessible to which people? Which parts do your developers need? Which parts do your admins need? How do you influence our backs? How do you implement a service catalog? How do you make it completely self-service so that it's as easy to use as possible? So when you dive into this a little bit more in detail, it's more than just how do I create a template that deploys a VM on Amazon? Or how do I create a template that allows me to deploy in our VMware instance? Again, it's about workflow management, quota management. How do you integrate into your financial systems? How can you convey to everyone from management to end users how much of the quota you're using, how much money each of these pieces is costing? What is your total spend across all of your pieces that you use on a daily basis? How do you implement this in the context of a hierarchy of people that have different access levels, our backs? And so there are many pieces to this puzzle. And as much as I'd like to say that there's one tool rule of the mall in the form of Managed IQ, the fact of the matter is it's extremely complicated. It's not an easy problem to solve. As many of you know, who have to administer this sort of thing, it's not easy to get beyond. And now with the arrival of more and more people moving to the microservices model, more people moving to the container model, there's yet another layer here that needs to be managed and sort of brought under the fold. Just a quick survey of people here. How many of you today use public cloud services, whether it's Amazon or some other? Yeah, okay, that's kind of what I thought. How many of you have VMware instances that you have to manage somewhere? Okay, open stack, docker. Nice. So yeah, no one's going to use in one of those 100% of the time. And some of them are going to be used to manage others. I mean, VMware isn't making a play to have container management be part of future products. Everyone seems to be jumping on the container train. So yes, it's a complex beast. And there are different trade-offs when you want to abstract away above the individual platform, the trade-offs between usability and finer grained features and functions that inevitably have to be made. But we're confident that managed IQ as a tool is useful to admins who have to do multiple platforms at the same time. So when you think of cloud operations, how am I doing in time? Oh, okay, good. When you think of cloud operations, a lot of people think of just provisioning. If cloud operations were just about provisioning, this problem would have been solved five years ago because it's much more than that. There is a history of cloud brokers being used to deploy different applications and services on single or multiple clouds. That's been done many times. It's much more nuanced and complex than that because after you deploy, what then? How do you deal with security exploits that inevitably come about? You've got these massively scaled-out applications and architectures that encompass multiple platforms. How do you deal with the fact that, say, half of your virtual machines could now be vulnerable to a specific attack? How do you architect around that? How can you do that without suffering a service outage? These are all things that inevitably come up. How do you end of life a service without disrupting the delivery of that service? How do you deploy or provision based on specific parameters that are designed to enhance the experience of the person who has to use those services? They're all part of the same puzzle. And this is where a tool like Manage IQ is built, is what it's built for. Of course, it's not without some work. There's a little bit of customization that has to be done. But out of the box, this is the problem that it's designed to solve, which is the complete lifecycle management of cloud and virtualization platforms. So, any questions so far, any comments or anything like that? Otherwise, all. Sorry. Yeah. The guy behind it, there you go. Just to make it more okay. Hi. Go ahead. We're looking at sort of cherry picking some of the features across some of the different cloud providers using cache servers based on Amazon, database servers hosted elsewhere. So, do you see this sort of blended operations console helping someone like my organization? So, I'm sorry, I didn't catch that last point. We're using services from different cloud providers. Right. Cloud Foundry from Amazon. Okay. Front-end caching and stuff. Database servers in other areas. And then our own private data center stuff. So, we have this mesh of nodes running in different physical locations in different cloud operation facilities. Do you see this technology working in that way? Consumably, yes. There are certain, in the managed IQ space, we call anything that offers a service a provider. And so, it comes with certain built-in providers that let you deal with compute and storage from say AWS or vSphere or some other platform. In the PAS space, we have not yet built specific connectors to any specific PAS. Although, as you can imagine, we are all working on that, especially in the context of containers and those who want to manage Docker at a very large scale. So, I guess the answer is not yet, but frankly, today you could create that if you wanted to. One of the things we're working on right now, and I'll get into this more and why I get into the community portion of this, we're working on a way to make it easier for people to create providers, new providers for the managed IQ dashboard so that if you want to fit in new providers, it's much easier to do that. It's not there yet, but the code is being developed as we speak and should be at least ready for initial consumption in say a month or two for the next release. And I'll get into that in a bit. But yeah, that's precisely the thing we want to solve and for a lot of different services and providers we're there and for some we're not. And that's one of those we'll be working towards providing. So let's go to the community vision. Why are we doing this? For one thing, open source is what Red Hat does. We've done it an entire existence. Managed IQ was something that we acquired in late 2012. It was the only proprietary piece of software that Red Hat had until this past June when we finally open sourced it. Our customers expect us to open source things and if we don't, they start to ask why because we've conditioned them to expect open source products from Red Hat. But also because we open sourced Managed IQ because there was no single player in this space that had really had a large market share. We looked at it as something that had significant demand and that there was no one really at the moment meeting that demand. And so thus the reason for open sourcing Managed IQ. One thing we wanted to do was we wanted to make sure it wasn't open core. Let me get a little bit short on time so I'll breeze through these. We did not want to be your traditional, the usual commercial open source project where it's this dinky little thing that kind of sucks and we really want you to buy the real thing. We don't like that model. We look at the open source community as a place for people to have the freedom to fail where any idea can be presented, anything can be done. It's up to the user or developer to implement it and make it happen. If it works great, if it doesn't, well, so be it, we can all learn from that. But the important thing is to make it accessible to everyone in the community so that if someone has an idea, anyone can bring it forward and actually work on it and collaborate on it with other developers. But really it's about making that open source upstream as dynamic and active as possible because that's how the software improves and that's how we all learn from and grow from it. And so we went through this process and there was a, frankly it was kind of a, if you've never actually taken a proprietary product open source, I highly recommend you start because you learn all sorts of things that you didn't know previously. All sorts of things that need to be replaced because they're licensed by third parties, things that can't be open sourced and so you have to rewrite them. It's a very instructive process to go through. In particular, if you're talking with the same developer team that built the proprietary tool and they've never dealt with open source before, that adds another dimension to the whole thing. I wrote an article about it on opensource.com if you wanna search my name there. So what we've done today, we open sourced it in June. The first release, we had the first major release in August, it's the Anand release. We're naming our releases after chess grandmasters, so the first release is Anand, named after Anand Vishwanathan, which I probably just butchered. The next one's gonna be Botvinnik, which is named after a Soviet chess grandmaster from the 50s. We went to market with about nine different partners. We've added a couple more since then, a couple of them based in Australia. And we wanted to be clear that this is for, again, getting back to one of the previous slides about open source being about the revenge of the customer and the end user. We want this to be a community that's useful to both end users as well as developers. We want people to be able to use it to do real work, whether or not they pay us any money. And we want developers to feel that this is something that they can contribute to you openly and something where all ideas are given credence if they're good. And the ultimate plan is, we can only do so much as with a core team. We wanna grow that core team to include others, particularly non-red headers. We want to basically create something that's greater than the sum of its parts, depending on the traction that we get with different partners, depending on how much other organizations and institutions want to contribute to the project. Because we went from being this tiny little startup to being a red hat acquired company. At each stage, we added resources and now we're open source and we're looking to really make an impact on the cloud management space. Because frankly, when you look at the pain that people have to deal with, systems management used to be about, we've got these bare mill machines and we've got these software installed in each one and that was bad enough. But now systems management is about that even to the extreme, where it's not just your bare metal pieces but all these other pieces that sit anywhere around the world and frankly you don't even know where they are at any given time around the world. But you still have to make sense of it and you still have to make reliable applications based on that that stay up at all times. And when we look at developers we want to work with, we're thinking in terms of how can we fill the gaps? What are things that we need to work on? How can we tie all this stuff together in a way in some sort of cohesive narrative that makes sense to end users and developers? How can we make their lives easier? How can we make life easier for developers who want to write to a RESTful API, just one RESTful API without having to worry about 10? How can we make life easier with a comprehensive dashboard for admins? How do we make it easier for users just pick and choose the things they want without having to worry about all the things that go underneath that? A little bit on roadmap so before I wrap up here. Like I mentioned we had a non-release in late August early September. The bot Vinnick release is coming up in March slash April, somewhere around that timeframe. Some of the features we're working on include better support for Hyper-V. We're looking at a better RBAC security model. We're looking at another thing here that I didn't mention. We look is the part about making providers more pluggable. So if you want to create, if you want to allow access to different service providers you can do that more easily. That could be coming online, like I mentioned, in a month or two. And then it'll be part of the next bot Vinnick release. Oh there we go. So the other thing we've done recently is we've, for about five years, we had this really good SOAP API. We always like to brag about our SOAP API. Not many people talk about SOAP APIs anymore. So we wrote it, replaced it with this Russell API that is hopefully something that people can use to script things together across all their different cloud platforms. And we've also looked at adding more support for cloud formations, pieces of orchestration, like heat, being another obvious example. We're looking at ways to work with, integrate with Tosca. Different things that make it easier for people to deal with orchestration across multiple platforms. We had our first design summit in October. We had representatives from 17 companies, seven countries and three continents converge on lovely Mawa, New Jersey, which is not a place that people go to do anything, frankly. But we had over 70 people come to talk about the NGIQ and the development roadmap for the botvinic release. It was pretty well received. There was a lot of enthusiasm for it. We're looking at hosting the next one in April and in Washington, DC. For those of you who are US based, great. If you're not, start planning now and save your dates. One of our partners, Booz on Hamilton was instrumental in putting this together and they'll be hosting the next version in April. So we'll look forward to that. These are the founding partners. Since this time, since I put this slide together, we've added two more. So I'll have to throw them in the next version of the slide deck so that they don't go unmentioned. And that's essentially it. I think that takes up my time, but I can field I think one or two questions before I roll it to the next speaker. Is there anyone with any questions or? One, okay, two. Try and squeeze two simple ones. First, what language is it written in? Ah, it's Ruby. It's a Rails application. Okay. Second, to manage lots of different virtualization systems, you'd need a lot of different, you'd have to, I mean, is it possible to be genuinely useful across many kinds of systems that have, you know, very different kinds of aims and purposes and, you know, to cover them all? Or are there big gaps? And that's why I mentioned that there are trade-offs. What you're getting for ease of use, you're giving up, say, some features and functionality that are unique to an individual platform. Yeah, you can't cover everything. So that's really up to the individual as to whether it's a trade-off worth making. Having said that, you know, obviously there are tools and places in Managed IQ that you can compensate for that. It just requires some customization. So it really depends on which project you're working on and what exactly you need to do. Hi, yes. I'm curious about what you say, the removal of the proprietary libraries. I'm sorry. Yes. Further down, okay. Removal of proprietary libraries. Oh, proprietary libraries, yes. That's what I say. Oh, yeah. So did you follow any specific process or you just say, okay, we need to get rid of everything? We, I mean, I think initially, we tried to work with the vendors, those libraries to see if we could talk to them about open sourcing it. And when that failed, we said, okay, we have to rewrite it. And that's why it took us probably, you know, over a year from the time that we decided to open source it to the actual release, a lot of it was just, a lot of them had to do with like the UI components. Like a lot of those UI, you know, JavaScript libraries were proprietary and we had to just rewrite them to do the dashboard. So a lot of it was dashboard specific. This stuff that was underneath the dashboard was pretty much all stuff that we wrote. So open sourcing them was, you know, not an issue because we owned the licensing, the copyright. But the third part of libraries, I think there were three of them and they were all sort of dashboard UI focused. And those are the parts we had to rewrite. We used a couple of different things. And there's one in particular that we, an open source tool that we used developed out of Hungary and I'm missing the name, but if I can think of it all, I'll tell you. Thanks. I'm forgetting. Oh, ah, okay, excellent. All right, thank y'all.