 Hi guys, my name is Frank Wu with Red Hat, and I think we'll just get started. So I'm a Cloud specialist at Red Hat. What that means is if you are a Red Hat customer and you talk to your sales rep about containers, Cloud, OpenStack, whatever, they bring in somebody like me to talk to you or one of my peers. So this talk I put together is really brief about to OpenStack or not. And I'll try to talk slowly because the non-native speakers earlier would like saying you should talk slowly, but I also live in New York City and I tend to talk fast. So let's me, oh shoot. This is going great. Thanks guys. I'm sorry. So it's fireless. So one of the reasons I asked the customers, what do you guys want to go to OpenStack? A common reason, wait for this to load is that they don't like their vendor. They want to have a vendor neutral platform which OpenStack was often positioned as. And I think that's a fine reason. Maybe you have a disadvantageous financial relationship with the vendor, but change is hard, right? Technology is pretty easy to change, but people in process are very hard. In IT, it's no different, right? Your developers today probably has their Emacs VAM set up very nicely. And on the operation side, people are used to their monitoring tools, their logging tools. The picture I put on the left is actually Google's data center, which is color coded for some reason. I don't know what it means, but I figured the ops guys like it, right? So change is hard, right? Why do people really change, right? Bring about technology change. Usually it's a business initiative, right? I won't go into the details of this, but it's usually on the business side at the C level where they're saying, this is where we're going in the future and the organization is investing in real technical effort as well as managerial effort. And it often involves external client initiatives. So before I talk about scenarios where I think OpenStack is a fit and OpenStack is not, I did want to put a disclaimer, I'm a Red Hat employees, right? So today this is from an individual working at Red Hat and obviously my viewpoints may be distorted. Why should you care about Red Hat's opinion? Red Hat is one of OpenStack's largest proponents, right? They spend a lot of money investing in the projects, hosting the summit, so on. But OpenStack is not all we do, right? So OpenStack is not the only hammer I have to the solution when talking to the customers. There's other approaches, methodologies, things that you can do to leverage besides OpenStack. So this talk is really kind of to OpenStack or not from a slant of Red Hat's perspective, specifically an individual working at Red Hat. So first scenario I run into when I talk to customers, you know, I have OpenStack expertise, right? You know, maybe one or two individuals came from PayPal or Comcast or Walmart and this is a pretty easy one for me, right? You guys know what OpenStack is. You've operated a cluster, you've gone through the pains of managing a life cycle around OpenStack, right? This is, to me in my mind, okay, this is a good fit, right? This is a potentially a good fit. What about scenario two, where a customer goes to you and says, Frank, I want self-service VMs, right? Today I just want to present and use your catalog where they click a button and have a virtual machine automatically provisioned. Today it takes us six to eight weeks. It's a very manual process. We don't have any AWS usage yet, but this is something we want to get ahead of the curve, right? And I think this is an interesting use case. Is OpenStack a fit or not? So oftentimes the hypervisor is VMware vCenter. So one approach that someone could take instead of putting around OpenStack is this idea of putting a self-service portal on top of your existing hypervisor where an user can log into a catalog, click a button, and that calls vCenter to make API calls. You can actually integrate in an orchestrator, whether it's Puppet, Chef, Anspo, whatever, to do other integrations. In the case of Red Hat, we have a product called CloudForms where someone could click a button within CloudForms to create a VM. CloudForms could call ServiceNow, go through your approval queue process, and then call vCenter, which creates a VM. CloudForms today could actually integrate into other parts of the infrastructure as long as there's an API. But if your infrastructure provider does not have an API, you could technically write an Anspo playbook and then just run that Anspo playbook, right? In this case, the user has a self-service portal without ripping out their entire infrastructure and existing expertise. You know, some key words people are looking for is these are typically brownfield environments, they're not greenfield environments, and people are really looking for billing and chargeback around this. Keep in mind, CloudForms isn't the only product that does this, right? It's vRealize automation, but I think it's important for people to realize if they're trying to solve a problem, you don't just want to look at the latest buzzwords, but there's other approaches that you can do to solve any user problems. Similarly, the largest environments taking this approach are excess of like 45,000 virtual machines, right? So the approach does scale. Sometimes I have this conversation with customers and they say, Frank, I think you hear me, but you're not really listening, right? Cause everyone's polite in these conversations and you know, after I explained this approach, they go, look, I'm really just trying to get away from my hypervisor vendor, right? That's not what I told you in the beginning, but you know, cost is really a driving factor in this, right? You know, I believe, you know, the customer talking that the hypervisor has slowly become commoditized, right? And there's a lot of higher additional features that I don't need necessarily, right? That I'm being charged for. And really we're trying to drive down our cost and get to a more efficient platform. And I think that's great, right? Especially now that customers are telling me kind of their driving factors at cost, but if cost is a driving factor and the hypervisor is completely commoditized, according to you, one question I'd be interested in is, guys, why haven't you looked at Microsoft or Hyper-V, right? Most large enterprises have large agreements with Windows. Maybe not everybody has a ton of Microsoft exchange servers lying around, but Hyper-V certainly should be under consideration. Similarly, Red Hat has a product that's KVM-based covered enterprise virtualization with similar functionality as HA, DRS, and so on, right? Again, this is an approach where you're solving your problems around cost, but you're not ripping out and changing the way you do networking or storage, right? I'm not saying this is the right or wrong answer, but it's something that you should consider. Scenario four. All right, Frank, this is definitely an open stack, right? We have a DevOps initiative that the CIO is saying that we have to get an idea into production faster, right? From the Java code to developer types in their IDE, I want to take that code and put it into production faster, right? And typically, you can't say the word DevOps without saying Jenkins afterwards, right? That's what everyone likes to say, but in my mind, a lot of people don't realize is there's this thing in Kubernetes, an OpenShift, where we have built in a last CI CD integrations, right? Where we have something called source to image where a developer can take their Java code in their IDE, push a get command, that code gets sucked into a Docker container image and then runs a CI job within OpenShift and then gets pushed to production. OpenShift actually ships with the containerized image of Jenkins, right? And everything is built in, right? So it's a very nice CI CD workload. So is this an open stack opportunity? Well, maybe, but what if you already have an existing CI environment outside of containers? It doesn't have to be Jenkins, it can be TeamCity, Bamboo, whatever, and you can certainly integrate that into your STLC process within OpenShift, but it's living outside of containers. What about if you have an existing repo for your artifacts? That's an artifactory. OpenShift comes with a container registry, but some people like to use artifacts to store their container images. Gee, I wonder if there's a way I could automate and tie in parts of my infrastructure. In this case, I think it's a great fit for OpenStack, because it's not just about virtual machines and containers, but it's about all these different environments and automating that process end to end, not just within that container orchestration system. So in R06, we have a very hot project, right? Business is funding it, it's big data, it's blockchain, it's Hadoop, whatever. I'm taking this as an opportunity to transform my organization to use OpenStack. There's certainly business value that OpenStack has in some of these applications like Hadoop. If you think about the idea of agility, right? Where if Hadoop was running in virtualized machines, there's this concept of rapid prototyping where somebody can spin up clusters quickly and spin them back down, right? There's certainly value on that. But before jumping in, I think the two questions people need to ask is, one, what is the minimum viable product or MVP that the business is trying to prove by testing these emerging technologies, and what is the timeline that you have on proving this out? In this case, OpenStack may be fit for you, but you may be wanting to look at managed OpenStack services, right? Or again, if there's value in that agility. Scenario seven, strategic hosting. These are large providers where hosting is really viewed as a strategic competency of the organization. They may have large steady-state workloads where the pure cost economics is OpenStack as far superior to a public cloud, but they also want control and governance, right? There's certainly more flavors today in the public cloud around CPU-intensive workloads, memory-intensive workloads, but there's nothing like having your own platform that you can control and optimize for your applications on. Scenario eight, and this is the last scenario, is everyone is bought-in, guys. The networking team has been sewed on Cisco, ACAD, they're moving to SDN. Storage, we're bought-in to this idea of block storage, how even our virtualization teams, the Windows guys and Linux guys are in agreement, right? We're moving to this new hypervisor. Red Hat, please come inside, just do a POC that's stand-up OpenStack, just do some upgrades and show management that we can operate this. Here I think OpenStack is certainly a fit, but my only caveat I would say is you wanna be wary not to have a zombie cloud where you're staying up OpenStack, right? So in these scenarios, I think it's important to dig into the use cases and go back to the lines of business in terms of guys, what are we actually gonna be deploying? Because the success metric of the project shouldn't be whether or not you stood up OpenStack, it should be about what type of workloads did we get on there and in the DevOps use case, right? We shortened our software release cycles from two months to two weeks. There's real value there that you can tell at SVP versus, hey, I stood up a Linux cluster. So I know I've been talking fast, so hopefully you guys found this talk helpful. I think that the takeaway is technology choice is not jeopardy, right? It's not like Buzz, what is Anspo? I'm gonna automate my VMware infrastructure. What is OpenStack? At the end of the day, we're just trying to make the best choice with the limited amount of information we have at a given point in time. But I hope that you guys found this talk helpful in seeing where OpenStack solves some problems and where other tools may also help solve some problems besides just throwing out a bunch of buzzwords. So thank you.