 Ladies and gentlemen, please welcome to the stage Matt Hicks, VP of Engineering for OpenShift and Chris Wright, Chief of Technologies from Red Hat. Thank you guys very much. So I'm Matt Hicks. I have been working on OpenShift for a while now. So I wanted to take a quick poll just to understand how long, how much experience people have with it. So raise your hands if you fall in the group. I'll keep making it progressively tougher. Take your hands down as you go on. So how many people have worked with OpenShift for at least six months? Raise your hand. Okay, that's good. That's a good premise. What about one year? Two years. Three years. That's good. Yeah, that's right. These guys are cheating. So we're getting close to six years now since when we started OpenShift. And it's pretty crazy going back to what we were thinking of six years ago to standing here in front of this room and seeing all of the momentum, the different organizations, what's happening in the industry. So I really appreciate that. I want to say thanks on behalf of, especially the Red Hat team, but as well as a lot of other people working with these technologies, because it's an exciting time. So given that, what Chris and I were going to talk with you about was the why this is an exciting time. We both have the opportunity to get to talk to hundreds of customers in various states, large ones, small ones. So we broke down the trends that we see happening, both the technology trends, some of the challenges that people are having. We're all excited about this technology, but not everyone is able to apply it right now. Why is that the case? There was a note to the elections. I will be the depressing part of this, and then Chris will bring you up at the end of the conversation and talk about how we as Red Hat think about this, what we see, what we're focusing on to solve the problems. But let's start with this. Most of us, I think, are here. IT is just a means to an end. We're trying to build that application for our business or for ourselves or for our company. Something that is pretty unique in the last couple of years is that the next generation of these applications that are going to win, they have to utilize dynamic infrastructure. No long can we have a great idea and build an app, and that's going to be all we need, because user expectations of these apps scaling, never going down, being able to be borderline like artificial intelligence with recommendations, those things are at a flawless expectation. We joke sometimes like Google search never goes down, but that is the user expectation for everything these days, and it requires this combination of both the applications as well as the infrastructure. Now, this has really been driven by three technology trends that we've seen. Application architectures are changing quite a bit. Those of us that have been in the field for a while, probably built our monolithic like PLSQL applications or massive like single instance JSB applications, but that's been slowly breaking up into more componentized views called microservices today. Same thing's been happening on the development process. We used to plan everything up front. We know our accuracy rates with that waterfall. They weren't great, and we're trying to adjust those to get more towards dynamic and agile processes. Then application infrastructures change quite a bit as well, from monolithic proprietary stacks to on-demand cloud-based infrastructure. These are pretty big trends we all know about them, and one of the things that is starting to link and amplify these is containers, because container sits in the middle and it really starts influencing all three of these, and how you would use them. One of the challenges we have structurally with this is cool stuff, like why aren't we all using it, is that when we look at how IT has grown up for most companies, it's really in two separate worlds. We have an operational side of the world that carries pagers, keeps things running, and we have a development side of the world, and maybe they meet at our CIO and maybe they don't. The problem with it is that it's worked really, really well for a long time. You think they like the history of IT. You build muscle memory around things that work. This is a pattern that for 20 years has arguably worked well. Now, this pattern is starting to fundamentally break down because of our users. Our user base is more diverse, it's more volatile. Diverse in terms of clients, how they're going to access things, geography. Volatile in terms of five years ago, the chances of launching a great app and having 20 million users show up in the first week, generally not possible. It just wasn't going to happen. Maybe it happened to 0.1%. That's a reality for apps that launch today. If you hit that good idea, that is the user base you'll have. I think even Pokemon Go will probably come up. That was roughly like their first week adoption that they had come in. This means this separation across our groups, it doesn't work anymore. This is one of the structural things I think we have to look at connecting these. Now, to compete going forward, both development and operational alignment as well as applications and infrastructure, these are a key area that we're going to have to balance across. If you take a step back, it's pretty obvious. It's like, well, we have to use both groups. We have to use their talents. What actually is getting in the way? We're excited about the technology. We know there are things we could apply and use with it. What keeps companies from actually applying this earlier? We broke this down to three areas. Again, I'm the problem guy and then we'll bring up Chris to talk about what we are doing. The first problem, infrastructure more likely than not is viewed as limiting your apps, which is a little crazy. You think about it like if you own infrastructure, you own servers. They're already racked. They're accessible. This should be in the asset column, not the liability column, but more companies than not. When you talk to, they view infrastructures holding them back. Why is that the case? One reason is applications' expectations for resources have changed. That means if you're on the operational side, what you built your infrastructure for is probably not what apps need today. This creates a challenge in terms of that asset or what should be that asset might not be that well-applied to your applications. The second challenge that we've seen talking to companies is that if we picked one area where there's almost ubiquitous investment on the operational side, it's with virtualization. Phenomenal technology lets us take big iron servers and carve them up into smaller pieces. That changes the supply side of operations. They can provide more virtual machines. It never really cracked into the demand side of developers. There was a select group that knew how to take these machines and use them better, but it didn't hit the mainstream developers. Those two things leave us at odds of the infrastructure we have and what that infrastructure needs to do. That's the infrastructure problem. The second problem we hit is that operations teams just curious how many people here in the room raised their hands if you would consider yourself on the operations side of the house. That's cool. I have carried a pager before, so I speak with some empathy of if you're on the operations side, your world is pretty challenged right now. One of the reasons is that companies of about any size have a span across these environments. Physical environments, dare I say even like mainframes are out there and more companies than not, virtual environments, private cloud environments, public cloud environments. Then some of us actually said, you know what, the public cloud will save us all. We're going to move everything there and life's going to be good. Even the companies we know that have pushed very hard in terms of how much they can move there end up being multi-vendor in public clouds. What your life as an operations person looks like is the span of environments is not going away. You need a way to operate in this space so that you have an abstraction point. You can apply something to all of these so that you can actually free up that time to start investing in new technologies. This is the second challenge, it's just the operational complexities killing us. The third challenge we go through is scaling development. It's exciting, I'm a technologist. I love learning about new technologies and this is a good time to do it. But at the same point, if you're trying to scale development to 100,000, 10,000 person org, it's really quite overwhelming these days. Every week you wake up and there's something new that you have to learn and apply. If you look at the classic like development breakdown, we're still solving the same problems. The tools in our toolbox are largely the same, whether it's we're applying messaging techniques, clustering, batch analytics. The tools we have haven't changed all that much. But one of the things that has changed is that these tools are running across this operational span of environments. And what happens in areas like this is tools work differently depending on where your app is deployed. This becomes pretty challenging. Clustering I always love to use as an example because clustering's take J-boss. You use something like J-groups, it's worked forever as far as you're considered as a developer. Then you move to the public cloud and it doesn't work anymore. And you have to learn like, well it's dependent on this thing called multicast and you're not a networking guy and you have to dig in and figure out what that means. But it's different, it's changed. That's not available to you anymore. And I like to use the analogy of if you were a carpenter, I like woodworking, you spend a lot of time learning how your saw works and your hammer so you don't hit your thumb. Imagine if every house you walked into, your tools worked differently. That's sort of the modern day challenge as a developer. Every place your operations team puts the app, it's going to work subtly different. Your operations teams are struggling with actually understanding all of this. They certainly know what multicast is but they don't have the time to explain it to you. And as a developer, you have to dig in layers and layers and layers deeper when you just wanted clustering to work. So that becomes a big challenge in terms of how we scale up to large development teams. Whether you're a startup trying to go from 10 to 20 people or whether you're a Fortune 10 enterprise going from 10,000 to 20,000. So these are the challenges but I think more exciting than that is how do we get past them because I've been in this space for a long time and I think this is the best point in time because we've actually seen technology solutions that I think will make a huge dent in these challenges going forward. So with that, I wanted to introduce Chris Wright and Chris will do the more uplifting side of how we're going to solve these. Chris? All right. Thank you, Debbie Downer. It's the most optimism you'll ever see from the downside of a conversation here. Thanks, Matt. So, you know, we're talking a lot about how we can bring these new tools to bear against these challenges that Matt outlined and I think I really agree with Matt that this is a unique time in the industry where we've spent decades solving similar problems really with similar techniques and surprisingly having similar outcomes and here we're really trying to take a new look at how we can solve these same problems but really kind of take ourselves to the next wave of, I guess, innovation or evolution of the IT space. So let's take a look at some of the technologies involved and this is kind of a Red Hat view of the world. So if you look at the base, it's all grounded in Linux and this is something that as a long-time Linux person, of course we're excited about Linux has found yet another way to really make a huge impact on the industry. As you go up through this stack, you see in the middle we have OpenShift so today we're here all about OpenShift and it's that OpenShift component that brings the different technologies together and then at the top, you're still seeing that same core Linux exposed to applications. So what we're seeing here is for the first time we have all the technology pieces that brings together the different constituents. We've got developers that are trying to just get real work done and write code and put services into production. We have a bunch of subject matter experts that are helping kind of scale those development, those developer populations and we have operations teams that now have a set of tools where we can combine our efforts and communicate through the tools. So let's dig in a little bit to that. The first challenge we had was how can we overcome infrastructure limiting our apps? This one's obvious. Containers, containers, containers, right? We're all excited about containers. There's only one answer. It doesn't matter what the question is, it's containers. But there's a reason for that and I think the reason is we've spent a lot of time trying to figure out how we build applications and put applications into a runtime environment and containers have given us an awesome basic building block. That building block is both lightweight and it captures the essence of the application and its immediate dependencies without kind of carrying on the baggage of everything else in your infrastructure and dragging it down from the developer side down into the operations teams. So containers is really a critical piece and it's this notion that with containers we can connect the application to the infrastructure in an intelligent way. So in the past it's sort of been developers writing the apps and throw it over the wall and it becomes an operations challenge of how do you figure out how to put this app into production and how to match it to the infrastructure that you've built in theory as Matt was highlighting earlier to support the applications and if we have an impedance mismatch there you're not going to have a successful outcome and so this kind of core building block is really the beginning of bringing together applications, applications, sort of deployment patterns and expressing those directly kind of programmatically into the infrastructure. With the exception of this slide containers create consistency. So we were looking at this earlier and Matt said well it's Java, it's a Java problem. Java is the one outlier here. But the concept here is with a container you can build common images so you can leverage some of your subject matter experts who really understand the guts of the runtime that's important to your application. Those images can be moved around across all the different footprints that we've talked about and made accessible to your developer population. So you create consistency in the runtime environment because you're isolating the application it's immediate runtime from the underlying infrastructure and you're allowing a set of experts to really focus their expertise in a space that's not accessible to the entire developer population. And it's this kind of container and container platform that is creating this new opportunity for us and that's connecting the operations teams and the developer teams through a platform through kind of a communication mechanism that allows developers to express their needs to the ops teams in ways that actually make sense. It's programmatic. We're talking largely about APIs and sort of aggregate application definitions in code so that that means that the infrastructure teams are building something that's just there to support those primitives and the developers can really take advantage of how do you write your application to express your resource requirements and connectivity requirements across this infrastructure that we've been building for a long time and we've never quite figured out how to give the right level of APIs and abstraction to allow developers to take a more active role in the application deployment phase. And you hear a lot about microservices and then you hear this kind of argument back and forth in the industry of they're not really new service-oriented architecture it's been around for a long time. If you go back before we've had object-oriented programming we've had this promise for decades of somebody somewhere is going to write something and somebody else is going to reuse that and it turns out that we've failed in that ability to express kind of a high-level abstraction that's easily reusable. So we have object-oriented programs and there is some reuse within a single program. We have service-oriented architectures and to a degree we've been able to leverage reuse of those services. Here we're really just refining our view on how do we implement independent services that are reusable. And one of the things that I think is is really sort of a powerful display of this working. I was just recently talking to a bank in Asia Pacific and two things that were impressive to me. One, this bank went from concept to production with an application in six months. So this was a container-based application a microservices-based application container to production in six months and in my experience, working with banks sorry, not container to production concept to production in my experience working with banks it's usually concept to the first exhaustive hundred-page document takes about six months and so here they wrote the entire application deployed it, took that technology in a different group and reused some of the components that the initial group had built and that if that's not what we're trying to achieve here I'm not sure what is. I mean that to me was really impressive an organization who's typically not capable of moving this quickly and creating code reuse. Just looking at how we've historically allocated services to infrastructure as we provide better tooling and use a container and use a language to describe how an application fits together we can make better use of those resources so we're not confining a single application to a single server or a single VM and hoping that somehow that service that's trapped in there is reusable because there's actually a lot more information in that VM or even bare metal server than just a single application or a single service in an application. So how do we keep pace? I mean how can we really allow the operations teams to work efficiently in an environment where everything is changing all the time and I think the most important piece here is providing consistency so if you look at all of the deployment environments on the right-hand side it's varied it's internal bare metal it's your virtualization which in many enterprises that's not an open source tool that's doing the virtualization it's VMware you have private clouds on-prem you have public clouds off-prem just building from some common building block like Linux is really a huge step forward in creating operational efficiency and we're taking that concept here and just moving it to the next level so we'll talk a little bit more about how a container platform or a PAS platform creates that same kind of consistency for applications across all these footprints but really it's how do you create efficiency for the operations team it's consistency and finally everything is moving so quickly I have a lot of developers and how can I enable my developers to scale and really provide the business impact that's driving all of this we're not building infrastructure just for fun we're building it to run apps we're not even building apps just for fun building apps to run businesses and more and more businesses are fundamentally about the software that they're creating so how do you really stoke that fire see a similar picture here where now we have a platform layer abstraction for providing developers a way to interact with all of those different infrastructures so they can really focus on building the applications and combining the different services into an aggregate application rather than trying to dig down into those details of do you know what multicast is should you even care as an application developer when you're trying to just get your app to cluster and that clustering could be functional in one environment in-house using multicast it could be in your private cloud using something like Kubernetes Ping to discover a component a service in your application or maybe running in a public cloud you're using some DNS mechanism to update DNS when you have service components coming and going and that is something that requires some operational expertise that is just burden to a developer it's not really the developer's core competency or really interest where that developer's focus is on building code and helping the company differentiate itself in whatever market segment it's in so this platform abstraction creates this consistency for the IT side that we talked about analogous to Linux and creates an abstraction for developers to work with so they can focus on their real job and then you have organizations who are growing and scaling and with a large number of developers the chances are there's a relatively small number of those developers that have expertise in a key area so let's bring those subject matter experts to the floor front to help us understand key patterns so they're going to be in the best position to inform your average developer in your enterprise what the best mechanism is to ensure your service level agreement is met based on a deployment model of do I do a canary deployment or a blue-green deployment how do I ensure that I'm introducing change and not taking a hit against my SLA let's let a subject matter expert define some of those properties in the platform so developers again can really focus on what they're trying to achieve which is write code and push code into production that's exactly what I was talking about here you know again this platform becomes this communication medium between all the different stakeholders across the organization and this relationship between experts helping the developer population scale is one example of that so this is what we think of as the new foundation for continuous innovation you know we have a notion here that the world is speeding up and it's not really going to plateau it's really accelerating and part of it is because we're giving tools to people so that you can automate things and focus your energy on innovating and bringing new ideas so this kind of platform is what's critical to bringing innovation to the forefront and this is a very Red Hat centric view of the world this is really the breadth of the Red Hat product portfolio and besides the fact that at lunch you can't actually get food until you can cite 12 different products on this chart the point here is just to show we have a really broad product portfolio and it spans from the developer side and how you build your applications to middleware and services to the infrastructure that's running the application to management and security and a bunch of professional services and for us we can bring a lot of that together in the OpenShift platform and we work with our community partners and the ecosystem to really broaden this to what we are excited about as a major change in the industry so from the low level infrastructure from the bottom of the stack all the way up to the top of the stack this is a space where we're working together both our internal developers and our community members to build out this platform and focusing both on the operations teams where the infrastructure portion of Red Hat's developer focus has been really a couple of decades at this point up through the application layer which we've really brought to a new space with OpenShift where we combine different middleware components and CICD pipeline modern thinking around how you build and develop software all together with a single stack so again this is that picture that we started with this is how we're bringing together all the key stakeholders a lot of this is grounded in Linux and containers and container orchestration and I'm sure we'll have no shortage of conversation about that I could have paid you to ask that question so the question just so people can hear it was is it heresy to say I can take my existing applications and build new technology and platforms and the conversation that I'm usually in with customers is you're going to have a limited amount of money that you can spend on that new applications and you have to manufacture cash in some way like how are you actually going to fund these new cool things that you do and 99% of them are going to fund that by becoming more efficient in your existing apps and what I've been very passionate about since we started was we don't just want to be able to tackle the net new applications we want to make sure that we can run that like 80 or 90% of what you have we have some customers one customer like blows my mind that they're success for this they moved over a thousand applications onto the platform and these are not like exciting new applications these are lift and shift and run them now what comes with that is you're not going to like pick up an EE application that's written 7 years ago drop in an open shift and then like magic happens you're dynamically scaling but what you are doing is Chris I think articulated well as an operations team you're building some primitives there like you're going to keep a core fabric running and your dev teams can now say like hey you moved my EE app over here and I can't actually do a deployment without taking downtime that's okay like that's the life you live in you get an idle change request you can make changes every three months like that's where most companies live but if you put in a little investment now on this platform if you can cluster you can scale maybe now you can get to a canary deploy and so we've seen customers lift and shift literally thousands of apps and then start applying patterns because now it actually makes sense to put a little investment in that app and now I can't change windows I can't do it once every three months I can do them as I see fit because I can make changes and not take downtime and then that leads to a whole set of innovations of okay how do I refactor this app how do I break down so that's probably my favorite topic area and I feel like on the open shift side if we are not letting you move the vast majority of your applications into the platform we are doing something wrong won't fit everything don't come back workily business suite you want to pick up and drop it in but I think you know a broad swath of space really really is a good candidate great question do you want to talk about the data side sure and I totally agree we talk to a lot of customers and we can't abandon today net new is an insignificant fraction of what a large enterprise is doing so we cannot abandon that and we also have to realize that there may be components that never fit naturally into a container platform but services immediately around those immediately springs to mind for me is a main frame application and it's probably you probably don't have any developers that even know the cobalt it was the application was written in anymore but it's well understood how the transaction process happens inside this black box and you may be surfacing it or skinning it with some images that are facing the rest of your fast moving application in a way that kind of bridges nicely bridges the gap on the on the data side there was some some data shown at the cloud native day the end of cloud con in Toronto which showed adoption rates of container containers in the enterprise in the kind of teen percentage rate and which was face value compared to how much we hear about it feels low if you looked a year ago it was half that so what you're really seeing is it's very early days and it's accelerated growth and in a red hat perspective we see kind of similar numbers so it's you know it's good to see it from a more kind of agnostic industry view but early days there's no doubt that it's kind of up until the right and part of that is it's been containers and container technology have been really successful in the new application space and so helping enterprises understand where we can bridge the gap between the traditional applications and the next gen applications is going to be critical to helping at least a mass wide-scale enterprise adoption for containers that will cheat as well. I didn't see them in the audience but Will, Matt, Fairly, and Steve Watt can you raise your hand if you're in the room because I didn't know. Okay I see well so those two hands in the back there at least if you have raised your hands high so people can see it. Any data questions you guys have whether it's from like data storage options we have on Kubernetes to like can you run Spark analytics on it ask those two guys so fail the tough questions test they will not. There's one, there's a couple others are hanging out there's lots of people in the room that can do that and Ross Turk was going to come from Sef. I don't see him here yet but there are going to be a lot of storage people here today. Questions, yeah. Yeah sure so the question was basically the is the cluster type technology we talk about today is that basically becoming the new OS or the new computer that people talk to. Yeah I think real quick from my perspective a lot of times like computers or things we'll talk to about are the interfaces that people are used to working with whether it was G-Lib C back in the day for C developers and I think for a majority of developers if we do things right in these communities these will become the new interfaces that they're used to interacting to. It's what you will build your applications to as an operations team member and what you will be building infrastructure to serve. And I do think the cluster nature of it is really critical because of that introduction. It's like building applications that can only scale to a single box they weren't that limiting five years ago or ten years ago and they're crippling today. So I think both of those aspects are really true. We'll see that from the human aspect of what they identify with whether your applications are really high. I mean for a while Google had a bumper sticker type thing that said my other computer is a data center. It is definitely part of our modern environment where you have really spiky loads unpredictable response to application application development essentially and then I do like to paint a picture where you have the physical hardware doesn't go away but really it's about the abstraction being API focused and giving you resources that are somewhere within a data center not just how do I get some memory from this particular box because that's just not a scaling way to do development. My question is right now with our company we have basically basically two factions in our development teams one it's pro container and working towards doing that and one that's kind of an old school with the speed of deployment of VPS and whatnot. It's like well I don't want to use containers and they will generate a bunch of reasons why. What would you say is what I can go back with as argument as to why we can try to get them onto the pro container side of things. Who's younger? Honestly it comes from both sides. Can you wait them out? The anti-container is a split group of the experience, we'll go with the experience gentleman term and some of the newer, in fact to one guy that I have in particular he's really about let's launch a bunch of VPS with Erlang and we'll just use their engine. Erlang OTP I have been there so I would say there's probably a difference between whether they're using them and whether they have to care or not. I think there is an audience you'll see one of the projects we deal with is source to image. There's a class of developers it's not a bad thing that they're really going to live in their source and they don't want to be have to deal with how do you build layers properly and how do you deal with deployments and how those are changing and an overlay network. We try to accommodate both of those groups I would say one approach might be for the group that do they really not want to use it or do they just not want to have to learn it and if it's the I don't want to have to learn it but I'm fine utilizing it source to image and those abstractions to keep them where they're comfortable but still be able to apply so the technology is pretty good. Those that want to learn it we never try to put up artificial barriers I think one of the early things you've seen change from past now a lot of times we'll call it even container as a service today is you can step down as many layers as you want to understand there's very little magic I don't know if that's what I would suggest at least. The other thing is I think it's important to know the limitations of technology that we're trying to cover so just because you could containerize something doesn't mean that's always the right answer and you'll build a lot of credibility with the naysayers if you can talk them through some of the benefits and maybe acknowledge in a certain situation it's not the right tool for the job and that's okay we're not trying to reinvent the entire world containerized. Maybe some are but there's really are a spectrum of tools I don't know what the limitations are we can really put containers in the part of the org that really makes sense and the VPS case feels like it could make sense but I'm sure there's a bunch of details in there that having a real direct dialogue meaningful technology based dialogue without pixie dust and hype helps I work for Red Hat so I cover the public sector a lot of federal agencies container technologies usually when I get that question it's usually from operations and I think one of the things that people don't talk about is all the benefits for operations with containers and my background I came from the Department of Defense and I worked for doing R&D and I worked in operations and you know when something blows up on a Sunday and your cell phone starts going off your pager if you're in operations you go in you have to if you're in a VM you have to figure out what the old version of the application was you have to undo all the middleware steps undo any configuration changes that were done to the guest OS or the middleware that can be a really cumbersome process so when you're using containers just roll back to the old version and you have that immutable image I think that's really big for operations aspect and then there's a lot of visibility for operations that you also get with containers so knowing how services are all linked together as operations you don't really know or have that visibility in the traditional VM world job developers just deploying wars or something out to Tomcat you don't really know how all those pieces are connected together but when you use a container platform you have more visibility into it you know exactly what ports are listening exactly what services are talking to each other so going down those types of things with operations I think benefits how it can really help make their life easier is really helpful as well it's a good point one of the slides had a header up there that said something like separation of concerns or duties and to John's point clear separation of concern really helps both sides whether it's the developer side or the operations side