 Good morning, everyone. So if you know Chris, right, you know that I'm not Chris, right Chris couldn't make it for this presentation and asked me to replace him I I can't promise to be as good as as him, but I'll try to do my best So my name is Nick bar said I work at red at obviously as the director of product management for open stack So today we are going to be talking about what it means to bring cloud-native innovation to the enterprise and first of all we need to recognize the fact that what is constantly driving the enterprise today is the need for driving a digital transformation. What do we mean by that? Well, if you're an enterprise that was doing taxi, Uber is doing a digital transformation that you need to be following If you're an enterprise selling books, Amazon has been driving a digital transformation that you are now You have to follow. If you're in banking, you have the same drive. Everybody's business nowadays is being driven by the need to have their business to be using a new way of offering their services And in order to do that, there is a few things that needs to happen So the first thing that needs to happen is for the company to realize that they need to do this change But then, based on what sector they are on, they need to decide how they're going to be organizing this change But all of this is going to force a change in the infrastructure platform that they have been using Clearly, if you have the same attitude with your infrastructure platform today that you had 10 years ago, you're not going to be able to cope with change But that's not enough. That's not enough because it's not just a problem of technology It's a problem of changing the mindset of the enterprise The way we've been delivering resources in their price has been a very siloed way A way where you have, in the worst case, a team taking care of networking, a team taking care of databases, a team taking care of storage Another one taking care of the servers, another one taking care of the wiring And of course, because they are separate teams, they tend to never communicate together So we really need to change the culture within the company We really need to have the company realize that in order to survive, they do have to switch their culture, their processes And then have that being followed by the technology But in any case, IT must evolve It's not anymore a question, do we need to make IT change? The change has to happen And if you know a single company that says, no, I don't need to change, please tell me, I have not met that company yet So what does it mean? Obviously, we want to go from a change in process that goes in the way we handle project management We want to go from a waterfall model to a more agile model And let me take a few seconds to talk about the word agile here When I say agile, I don't imply taking a process such as Scrum and applying Dumbly to everyone The only thing that I care when I say the word agile about is how people are going to be able to very quickly have their method evolve within each of the teams How quickly can the feedback that they are going to be gathering about how they are doing their work is going to be taken into account to modify the process to go faster And when we are talking about this transformation, the goal is what people have labeled DevOps But if I take the case of Red Hat, DevOps doesn't really make sense Because in our process, we don't have ops and devs, we more have dev, QE, PMs, support engineers, consultant All these guys need to work together So DevOps is not more than something that is a reference you can use to talk about the same change But it needs to be adapted Agile is not Scrum Agile is you need to be able to adapt quickly Another change that you need to do is in your architectures The way you conceive your applications needs to be evolving You need to go from big monolithic applications that scale vertically to end here to eventually get to microservices You also need to change the way you deploy We were deploying before on physical servers We need to evolve to virtual server and eventually to containers And of course we need to change the way the application infrastructure is conceived We were previously talking about localizing application on data centers We moved the application to hosted data centers And now we really want the application to be anywhere we want The same application can be deployed on whatever resources we decide to use, whichever cloud Whether it's internal or external So this is a lot of change But the problem that we're trying to solve is this change is something that is not something that you're going to stop In fact, if some of you have been to Oskun a few years back A guy named Wardley was doing this great presentation called Situation Normal Everything must change And this is true and this is going to remain true over time So how do we help that? How do we as a Red Hat as a software publisher can help handling this change? Of course we are not a consulting firm so we are not going to come into enterprises and explain to them how to organize themselves What we can do is provide tools that support these changes, that support this transition That enables this idea that people must go from one point to another in a smooth way The notion of Big Bang cannot exist You do not transform all of your application overnight from monolithic design to a microservice design That's not true So we need to think of IT as something that is necessarily an hybrid model Hybrid in multiple axes Hybrid in public versus private Hybrid in the notion of do I deploy on physical server, in VMs or in container And I'm sure there is other dimension of hybridity there But our very important role is and will be always We need to enable a fast feedback loop And what do I mean by a fast feedback loop? We need to do something, deploy it as quickly as we can Get the feedback, analyze the feedback, take corrective action and do it again And the quicker we go in this loop, the better we are So I'd like to take a few seconds to give you an example The example that we are currently living within Red Hat When I arrived at Red Hat after the acquisition of Inovance Red Hat was producing OpenStack the same way Red Hat had been producing Rail for the past 15 years And one of the things that I realized at this time is Our time for delivery of a feature was about a year and a half From the moment a partner, a customer was asking for a feature To the moment we were able to put it in their hands Because of our internal processes, it would take a year and a half And guess what? This is exactly the time you have between two rail releases And that meant that this process that was in place Was perfectly feeding the slow pace of rail at the time But the reality is that we were dealing with a project Called OpenStack, maybe you know about it And this project has a six month life cycle And so people were telling us, but why are you so delayed Compared to upstream? And the time to delivery for a feature a year and a half Was a lot of freeloading but also a lot of post loading Between the time an OpenStack release was made And the moment we could ship it, it would take six months And obviously when we looked into it One of the problems that we found is that Our PM team talked once in a while with engineering We talked in a while with QE, but really what was happening Is PM were dumping feature requests onto engineering Very schematic here And engineering would develop, dump their stuff to QE QE would test and eventually then we would be able to ship Unfortunately this was not working anymore So what we did was to say, hey, we need to change that model We need to organize teams in a way where the end to end delivery Of a feature, of a set of feature or a component Is the common goal of a team mixing people from PM From engineering, from QE And involve documentation support and all other things As early as possible And of course the transformation was not that easy It was very hard to explain to people Why they needed to change the way they worked And in fact, even with the best intent We're always thinking that we had some avial mindset behind it That we were trying to bother them just for the sake of it And we had to wait for crisis, identify them to make people realize That this is why they need to change And this transformation is not complete But already we've changed our time to market for a feature For a year and a half to eight months It's huge progress And I hope to be able with the team to reduce it even further But this is just an example of the transformation that we had to do Which is an example that every industry has to go through So talking about our product for a little bit How do we transform the traditional application stack? Traditional application stack You've got physical hardware that runs an operating system Rail by preference of course Which can be software that comes pre-compiled Or with a runtime environment Lots of people are using Java or other interpreted languages And that's about it We have multiple applications running on the same box But an application is basically confined to one box And really where we want to get is the next generation infrastructure This next generation stack Can be represented as the base layer is not anymore the server It's the data center The layer on top of it is the VIM, the virtual infrastructure manager OpenStack in our case The layer above is either directly application running within VMs Or we introduce this notion of application orchestration And this is why everybody is talking about Kubernetes Or similar technologies And the reality is that going from the previous model to this model Does not happen in one day And in fact we need to be able to help our customer do this transition By providing the tools that deliver this The tool that help maintain this legacy application That there is no interest in changing Why would you change something that work While being able to enable this new application That are going to be communicating with this old application Work well together And every time I hear somebody telling me Oh, tomorrow all applications are going to be designed as Micro services running on Docker started by Kubernetes I'm telling this guy, hey, you should really go spend six months At a customer see what's the reality there I know no customers that have more than a single application To take care of that have been able to do a complete transformation Even over 10 years, even over 20 years I mean, 20 years ago what I was hearing when I 30 years ago now, sorry, when I started working in computing I heard, hey, tomorrow there will be no more mainframes Everything will be done through the client server model Where are we at now? There are still mainframes And there will be again mainframes in the future And as there will be client server application Because why change something that works If the digital transformation is important In the way you change your process But if the application works well in the context of that digital transformation There is no economic reality that is going to justify Modifying what exists So really enabling the transformation is what we do And how do we do that more concretely? Well, first of all, we are transforming the role of the OS The OS remains very important in any case Whether the OS is what you use when you're inside of a container Or the OS is what you use when you're inside of a VM Or the OS is what you use when you're addressing Your individual server in your data center There is still an OS It is still the thing that makes the virtual world talk to the physical world It is still the thing that is making the transition But what we can do is modularize that OS So that only what is needed is installed where it is needed The first example of this transformation that we are doing in our OS Can be embodied by what you see in the atomic server Our server dedicated to run containers And we are going to be evolving on that principle a lot in the next few years The second thing that we are offering is not one But two virtual infrastructure manager models One which is based on OpenStack And another one which is based on SteelKVM But a KVM model that is closer to traditional virtualization But why are we doing this? Because we know that some applications need the old virtualization model To build their full tolerance model And as we progress, it is clear that OpenStack gets more and more Full tolerance for application functionality And there will be a point where the two products will be merging In one way or another Because we will have feature parity between the two But in the meantime, offering a common networking layer between the two models Both are using Neutron, a common storage model between the two frameworks Both are using Cinder Is the way we help the companies that are transitioning from one model to another To maintain continuity between the environments And if we go up one level If we think that there is going to be applications that are going to be running in VMs And applications that are going to be developed to run within an orchestration environment Using containers, microservices These microservices that are running either on top of Rev or on top of OpenStack Do you think they will need to talk with their VM application Or even with the bare metal application that the company is still deploying? Yes, of course It's not because your database is still hosted on some mainframe That the microservice application won't need to be able to talk to it And this is why we are hard at work to make sure that our networking layer, Neutron In all cases, is being efficiently used by our orchestration layer when deploying containers And that's the career project within OpenStack This way we are able to enable continuous flows of information throughout the IT Regardless of the stage of evolution of the applications or the various applications in IT Does this make sense? I see a few people nodding, at least I haven't put everyone to sleep yet Thanks So another way we are trying to help is to address the same problem from two very different perspectives The first perspective is the perspective of the developer And as a developer, let's imagine I'm a developer for a second Those that have seen my code will wish that I'm not As a developer, the only thing I care about is how am I going to be developing the next application What's the next stuff, what's a great way to build my application tomorrow And that's great And this is why when we talk with developers, we will always emphasize our Kubernetes-based solution called OpenShift We're not going to be talking about OpenStack that much Well, it's not completely true because there is a small fringe of developers that I could qualify as system developers That really care about having access to a full OS And with these guys, we'll be having a slightly different talk But in general, in 90% of the cases, we'll be addressing the developer population of an enterprise With the tooling that we have to build microservice-based applications On the other hand, when we're talking with operators These are people that care about how do I plug my network into that box So that that application can eventually get an IP address And these guys, they need to understand how the translation is working Between the physical world and the virtual world And what is offering that, that's a VIM And our next generation VIM based on OpenStack, Red Hat, OpenStack platform Is the way we approach this population So a lot of people think that we are building two competing products And in fact, if I take a poll internally at Red Hat With the developers that are developing each A lot of them think that they are competing products because, hey, they are doing roughly the same thing They are putting bits in a box So box equals box equals competition But that's not the case They are building a tool that is complementary People that tells me, oh, tomorrow with Kubernetes I'll be deploying on bare metal servers by the thousands, and I will have no problem Well, those people have never looked at what it meant to be interacting with the physical layer Or with an SDN, or with hundreds of storage vendors One of the fantastic strengths of the OpenStack project Is not coming from the quality of its code Whether it is good or not doesn't really matter at this stage The real value of the OpenStack project is coming from A, the variety of the contributors B, the ecosystem that has formed around it And the variety of options that you have when you deploy OpenStack Regardless of storage, networking, whatever What's really important in there is that We are solving the virtualization problem independently of the application story And we have a great tool in the middle This orchestrator, Kubernetes, as we made a strong choice there That is offering the point where the two are meeting And we are actively contributing to Kubernetes To offer all the bridges necessary to ensure maximum transparency between the models I mentioned career, but the same efforts have been done in Cinder, in Manila And there is going to be more So, now let's take a look for a second at a little survey that we did on our customer base So we sent to every email address of a customer we could think of a survey Asking them to answer a few questions And 150 unique customers answered Out of this 150, we were really, really pleased to see a year over year increase Of 17% of the number of people going to production with OpenStack We also saw an increase in the question Are you planning to use a platform as a service Like an A&A, OpenShift or its competition We also saw an increase on the number of people planning to use containers on top of OpenStack So there is no doubt OpenStack is a material product You wouldn't have 42% of our customer deploying it in production If that was not the case OpenStack is a platform on which people want to run paths and or containers Another question that we ask is where should we invest And we made a very stupid mistake of asking two open questions The first one was do you think that simplified installation is important We got 69% But did they mean installation of application on top of the cloud Or did they mean simplified installation of the cloud itself Well, I can bet that we have again this ops versus dev point of view here From the dev side, the deployment of my application is obviously going to be my main concern From the ops side, simplified deployment of my OpenStack platform is of course going to be my main concern So yes, they are all caring about that And I don't think we learned much about it Except that I could talk for five minutes about it Now, 55% of them were strongly in favor of having support for complementary solution None of them think that there is one project that will rule them all And it shows that in many ways our customers with their business needs Have a much clearer picture of what their tomorrow is going to be than we have At least from the perspective I have from within Red Hat Also, 53% told us it was very important for them when they were selecting a vendor Which was that their vendor had some type of leadership in the communities for which they were building products upon And yes, if you're building a product, if you're building a product based on community bits You'd better be participating actively in that community That doesn't mean that you need to rule it If you look at Red Hat as a wide contributor Red Hat is sometime the leader in contribution to some projects Red Hat is sometime one of the main contributors But in all cases, we always prioritize the investment in the community over anything else In fact, you must have heard that a hundred times But we have a base philosophy which is let's do things upstream first And why do we want to focus on this idea of upstream first? Because it is the only sustainable way to build a product on top of community-based bits If you want, after this, because I don't like to name people on stage I could give you the example of at least five companies that were highly involved in the early stage of the OpenStack project And that have completely disappeared from the scene And in every case, they had one thing in common They were forking, they were building add-ons as monkey patches or whatever technology they decided to use And who is remaining now? Only the guys that really got it In fact, I'll give you an example of a very, very positive evolution of our community But in any case, we need to be focusing on the core services within the upstream community We need to be adding the value that our customers are asking for by working on our influence in the community If a customer is asking me for a feature and nobody recognizes me as a valued contributor to that community What are the changes that this feature is going to get in? Of course, our role as a distribution of an upstream community is to be mitigating the risks And we still have to do stuff downstream, but the last thing it is, it is to produce bits that are not accessible to others We might change configuration from what the default in the community is We might change a few logo here and there We might do quality assurance, we may be back-porting bugs for longer And a bunch of other things like tech support and documentation that nobody cares about But in no cases have I seen an example of a valid reason to do a fork to carry specific patches When you look at our investments in some of the communities that we have, these are not scientific numbers They can be contested in many ways, but one thing remains In all the projects that we ship, we have some kind of a major investment in that community Whether it is in the OpenStack project, the Kubernetes project, or the OPNV project We get people on the ground contributing code to it I don't think anybody can contest that, and I think I've explained why So one question is, hey, as a user, as a customer, as a partner, how can I help? Or I could formulate it in another way How can I get this one thing I really care about that nobody else care about? And my simple answer is, come on, join us, contribute upstream This is how you're going to be getting what you want out of OpenStack, out of any project you're talking about And secondly, make sure that you stop building vertical teams Stop putting people that do the same thing in the same management group They are going to build a little kingdom that will talk as little as possible to every other kingdom Because when you have a kingdom, talking to another kingdom is called a war Now, Game of Thrones is a bad analogy here Also, when you're building a dev team or an obscene that is going to be involved in OpenStack Don't expect them to only be servicing your cloud need Please give them time to contribute back to the OpenStack project Because this is how they're going to learn more about the OpenStack project This is how the OpenStack project is going to better suit your own need And this is how we are all going to be more successful together And a very good example of this is the announcement that we made last week, just before Summit It's a very good example because it's a case of a major vendor With whom we've been working for ages that has tried other models And finally came to realize that contributing upstream first was the right way to go And we've announced that we are going to be working together on this contribution We are going to be helping them on learning the processes They are going to be helping us in bringing years of expertise in an area where we are not experts In fact, Red Hat is experts in many things, in so many things that we are experts now We are very good generalists So having a partner such as Ericsson to help us succeed in multiple markets Including the enterprise, including the telco markets is really a great thing for us And thankfully, all the efforts that we've put in the past five years are starting to pay off At last Summit, we announced a few customers Not very significant, only four of them, if I remember correctly Well, yesterday... Hello? Yesterday, I don't know if you noticed, but we made a small announcement where we announced four more I don't know if you've heard of BBVA At least if you look around when you walk in the city, you should see a few signs It's a major bank in Spain You might have heard of BedFair BedFair is the largest bedding platform, I think, in Europe They are handling 130 million transactions per day, if I remember correctly Which is huge And they are doing it completely on top of OpenStack You certainly never heard of ProDuban But ProDuban is the IT arm of Santander I think you've heard of Santander Another major bank And CA Mobile And we are also announcing another wave today Of customers that have decided from the telco world to work with us So it's not just anymore the idea of working together It's a concrete example of people that are satisfied enough of their experience With OpenStack that are coming up, telling the world, hey, we are doing it And look, we are having incredible business returns based on this work I don't know if you've read this great presentation that was done I don't even remember where I think it was, Oscon Titled No CEO Ever But clearly having a customer be displayed What happened there Be displayed on this list is the demonstration that the CEO did see value In the end result of a transformation that we helped them initiate That this transformation was successful That we were able to provide the value that they were expecting So this concludes my presentation These are the sessions that you missed done by other Red Hat guys yesterday Don't worry, there are more coming today There are plenty of sessions done by Red Hat guys So I invite you to come and see them And the schedule is starting to run by itself, I don't know why Interesting Anyway, thank you very much for listening to me I think I'm out of time for questions in the audience But I'll remain around for a bit if you have questions Thank you