>> John Furrier: Hello, welcome back to theCUBE's coverage of Cloud Native Security Con 2023 North America the inaugural event. I'm John Furrier, host of theCUBE, along with Dave Alonte and Lisa Martin covering from the studio. But we have on location Emmy Eide, who is with Red Hat, director of Supply Chain Security. Emmy, great to have you on from location. Thanks for joining us. >> Emmy Eide: Yeah, thank you. >> So everyone wants to know this event is new, it's an aural event, cloud native con, coup con. Very successful. Was this event successful? They all want to know what's going on there. What's the vibe? What's the tracks like? Is it different? Why this event? Was it successful? What's different? >> Yeah, I've really enjoyed being here. The food is wonderful. There's also quite a few vendors here that are just some really cool emerging technologies coming out and a lot from open source, which is really cool to see as well. The talks are very interesting. It's really, they're very diverse in subject but still all security related which is really cool to see. And there's also a lot of different perspectives of how to approach security problems and the people behind them, which I love to see. And it's very nice to hear the different innovative ideas that we can go about doing security. >> We heard from some startups as well that they're very happy with the, with the decision to have a dedicated event. Red Hat is no stranger to open source. Obviously coup con, you guys are very successful there in cloud native con, Now the security con. Why do you think they did this? What's the vibe? What's the rationale? What's your take on this? And what's different from a topic standpoint? >> For non-security specific like events? Is that what you mean? >> What's different from coup con, cloud native con, and here at the cloud native security con? Obviously security's the focus. Is it just deeper dives? Is it more under the hood? Is it root problems or is this beyond Kubernetes? What's the focus, I guess. People want to know, you know, why the new event? >> I mean, there's a lot of focus on supply chain security, right? Like that's the hot topic in security right now. So that's been a huge focus. I can't speak to the differences of those other conferences. I haven't been able to attend them. But I will say that having a security specific conference, it really focuses on the open community and how technology is evolving, and how do you apply security. It's not just talking about tools which I think other conferences tend to focus on just the tools and you can really, I think, get lost in that as someone trying to learn about security or trying to even implement security, but they talk about what it takes to implement those tools, What's behind the people behind implementing those tools? >> Let's get into some of the key topics that we've identified and get your reaction. One, supply chain security, which I know you'll give a lot of commentary on 'cause that's your focus. Also we heard, like, Liz Rice talking about the extended Berkeley packet filtering. Okay, that's big. You know, your root kernel management, that's big. Developer productivity was kind of implied around removing the blockers of security, making it, you know, more aligned with developer first mentality. So that seems to be our takeaway. What's your reaction to those things? You see the same thing? >> I don't have a specific reaction to those things. >> Do you see the same thing happening on the ground there? Are they covering supply? >> Oh, yeah. >> Those three things are they the big focus? >> Yeah. Yeah, I think it's all of those things kind of like wrapped into one, right? But yeah, there's... I'm not sure how to answer your question. >> Well, let's jump into supply chain for instance. 'Cause that has come up a lot. >> Sure. >> What's the focus there on the supply chain security? Is it SBOMs? Is it the container security? What's the key conversations and topics being discussed around supply chain security? >> Well, I think there's a lot of laughter around SBOM right now because no one can really define it, specifically, and everyone's talking about it. So there's, there's a lot more than just the SBOM conversation. We're talking about like full end-to-end development process and that whole software supply chain that goes with it. So there's everything from infrastructure, security, all the way through to like signing transparency logs. Really the full gambit of supply chain, which is is really neat to see because it is such a broad topic. I think a lot of folks now are involved in supply chain security in some way. And so just kind of bringing that to the surface of what are the different people that are involved in this space, thinking about, what's on the top of their mind when it comes to supply chain security. >> How would you scope the order of magnitude of the uptick in supply chain attacks? Is it pretty heavy right now or is it, you know, people with the hair on fire or is it... What's the, give us the taste of the temperature in the room on the supply chain attacks? >> I think most of the folks who are involved in the space understand just that it's increasing. I mean, like, what is it? A 742% increase average annual year, year over year in supply chain attacks. So the amount of attacks increasing is a little daunting, right, for most of us. But it is what it is. So I think most of us right now are just trying to come together to say, "What are you doing that works? This is what I'm doing that works." And in all the different facets of that. 'cause I think we try to throw, we try to throw tools at a lot of problems and this problem is so big and broad reaching that we really are needing to share best practices as a community and as a security community. So this has been, this conference has been really great for that. >> Yeah, I've heard that a lot. You know, too many tools, not enough platform thinking, not enough architecture, needs some structure. Are you seeing any best practice around frameworks and structure around how to start getting in and and building out more of a better approach or posture? I mean, what's that, what's the, what's the state of the union for supply chain, how to handle that? >> Well, I talked about that a little bit in my my keynote that I gave, actually, which was about... And I've heard other other leaders talk about it too. And obviously it keyed my ear just because I'm so passionate about it, about partnership. So you know, empathetic security where the security team that's enforcing the policies, creating the policies, guidelines is working with the teams that are actually doing the production and the development, hand-in-hand, right? Like I can sit there and tell you, "Hey, you have all these problems and here's your security checklist or framework you need to follow." But that's not going to do them any good and it's going to create a ton of holes, right? So actually partnering with them helping them to understand the risks that are associated with their very specific need and use case, because every product has a different kind of quirk to it, right? Like how it's being developed. It might use a different tool and if I sit there and say, "Hey, you need to log on to this, you need to like make your tool work this platform over here and it's not compatible." I'm going to have to completely reframe how I'm doing productization. I need to know that as a security practitioner because me disrupting productization is not something that I should be doing. And I've heard a couple a couple of folks kind of talking about that, the people aspect behind how we implement these tools, the frameworks and the platforms, and how do we draw out risk, right? Like how do we talk about risk with these teams and really make them understand so it's part of their core culture in their understanding. So when they go back to their, when they go back and having to make decisions without me in the room they know they can make those business decisions with the risk as part of that decision. >> I love that empathetic angle because that's really going to, what needs to happen. It's not just, "Hey, that's your department, see you later." Or not even having a knowledge of the information. This idea of team construction, team management is a huge cultural shift. I'm sure the reaction was very positive. How do you explain that to an organization that's out there? Like how do you... what's the first three steps you got to take? Is there anything that you can share for advice people watch you saying, "Yeah we need to we need to change how our teams operate and interact with each other." >> Yeah, I think the first step is to take a good hard look at yourself. And if you are standing there on an ivory tower with a clipboard, you're probably doing it wrong. Check the box security is never going to be any way that works long term. It's going to take you a long time to implement any changes. At Red Hat, we did not look ourselves. You know, we've been doing a lot of great things in supply chain security for a while, but really taking that look and saying, "How can we be more empathetic leaders in the security space?" So we looked at that, then you say, "Okay, what is my my rate of change going to happen?" So if I need to make so many security changes explaining to these organizations, you're actually going to go faster. We improved our efficiency by 2000% just by doing that, just by creating this more empathetic. So why it seems like it's more hands-on, so it's going to be harder, it's easy to send out an email and say, "Hey, meet the security standard, right?" That might seem like the easy way 'cause you don't have time to engage. It's so much faster if you actually engage and share that message and have a a common understanding between the teams that like, "I'm here to deliver a product, so is the security team. The security team's here to deliver that same product and I want to help you do it in a trusted way." Right? >> Yeah. Dave Alonte, my co-host, was just on a session. We were talking together about security teams jumping on every team and putting a C on their jersey to be like the captain of the intramural team, and being involved, and it goes beyond just like the checklist, like you said, "Oh, I got the SBOM list of materials and I got a code scanning thing." That's not enough, is what we're hearing. >> No. >> Is there a framework or a methodology to go beyond that? You got the empathetic, that's really kind of team issue. You got to go beyond some of the tactical things. What's next beyond, you got the empathy and what's that framework structure when you say where you say anything there? >> So what do you do after you have the empathy, right? >> Yeah. >> I would say Salsa is a good place to start, the software levels. Supply chain levels for software artifacts. It's a mouthful. That's a really good maturity framework to start with. No matter what size organization you have, they're just going to be coming out here soon with version one. They release 0.1 a few months back. That's a really good place to give yourself a gut check of where you are in maturity and where you can go, what are best practices. And then there's the SSDF, which is the Secure Software Development framework. I think NIST wrote that one. But that is also a really, a really good framework and they map really well to each other, actually, When you work through Salsa, you're actually working through the SSDF requirements. >> Awesome. Well, great to have you on and great to get that that knowledge. I have to ask you like coup con, I remember when it started in Seattle, their first coup con events, right? Kind of small, similar to this one, but there's a lot of end user activities. Certainly the CNCF kind of was coming together like right after that. What's the end user activity like there this week? That seems to always been the driver of these events. It's a little bit organic. You got some of the key experts coming together, focus. Have you observed any end user activity in terms of contributions, participation? What's the story on the end user piece there? Is it heavy? Is it light? What's the... >> Um, yeah... It seems moderate. I guess somewhere in the middle. I would say largely heavy, but there's definitely participation. There is a lot of communing and networking happening between different organizations to partner together, which is important. But I haven't really paid attention much to like the Twitter side of this. >> Yeah, you've been busy doing the keynotes. How's Red Hat doing all this? You guys have been great positioned with the cloud native movement. Been following the Red Hat's moves since OpenStack days. Really good, good line of product, good open source, Mojo, of course. Good product mix, right, and relevant. Where's the security focus here? Obviously, you guys are clearly focused on security. How's the Red Hat story going on over there? >> There was yesterday a really good talk that explains that super well. It was given by a Red Hatter, connecting all of the open source projects we've been a part of and kind of explaining them. And obviously again, I'm keying in 'cause it's a supply chain kind of conversation, but I'd recommend that anyone who's going to go back and watch these on YouTube to check that one out just to see kind of how we're approaching the security space as well as how we contribute back to the community in that way. >> Awesome. Great to have you on. Final word, I'll give you the final word. What's the big buzz on supply chain? How would you peg the progress there? Feeling good about where things are? What's the current progress on supply chain security? >> I think that it has opened up a lot of doors for communication between security organizations that have tended to be closed. I'm in product security. Product securities, information securities tend to not speak externally about what we're doing. So you don't want to, you know, look bad or you don't want to expose any risk that we have, right? But it is, I think, necessary to open those lines of communication, to be able to start tackling this. It's a big problem throughout all of our industries, and if one supply chain is attacked and those products are used in someone else's supply chain, that can continue, right? So I think it's good. We have a lot of work to do as an industry and the advancements in technology is going to make that a little bit more complicated. But I'm excited for it. >> You can just throw AI at it. That's the big, everyone's doing AI. Just throw AI at it, it'll solve it. Isn't that the new thing? >> I do secure AI though. >> Super important. I love what you're doing there. Supply chain, open source needs, supply chain security. Open source needs this big time. It has to be there. Thank you for the work that you do. Really appreciate you coming on. Thank you. >> Yeah, thanks for having me. >> Yeah, good stuff. Supply chain, critical to open source growth. Open source is going to be the key to success in the future with automation and AI right around the corner. And that's important. This theCUBE covers from cloud native con, security con in North America, 2023. I'm John Furrier. Thanks for watching.

>> From around the globe, it's The Cube, with digital coverage of Red Hat Summit 2020, brought to you by Red Hat. >> Hi, and welcome back, I'm Stu Miniman, this is The Cube's coverage of the Red Hat 2020, bringing you guests from Red Hat and their partner ecosystem, practitioners, where they are around the globe, bringing to them this digital event, and while we wish we could all be together in person, we'll just be together apart for 2020. Happy to welcome to the program, a longtime Red Hatter, but first time, on The Cube, Rich Sharples, who's the senior director of product management inside Red Hat, Rich, thank you so much for joining us. >> Yeah, thanks for the invitation, great to be here. >> All right, so the topic we're going to talk about today is something you've got a long background of the middleware space. But in, Quarkus so, I personally was not familiar with Quarkus. Obviously we know, god, I believe someone told me once that there's like, 2 million open source projects out there, so I believe I can be forgiven for not having every one of them memorized there, but of course anybody in our community is going to know Java. What a huge impact that has had on the industry. Linux and Java are two of the, you know, major movers of how we, you know, build an, you know, deal with application today, so give us a little bit of a framework as to what Quarkus is, you know, why it was created. >> Yeah, so it's no secret that as organizations and developers move to this kind of new styled cloud native development, developing applications running in containers or in a kind of serverless environment that Java is not necessarily the best fit. Java does many incredible things, it's an amazing field of engineering. But many of the coolest things it does, assumes that it's going to be a long running application, it can do this cool dynamic class loading and dynamic optimization as the application runs. Those things are pretty impressive, but they're also fairly, very heavyweight. And in our kind of ephemeral environments, whether containers or functions of service, you don't have long running applications. And you can't make use of those things, so in a Java environment you pay for those radical features that you don't necessarily get any benefit from them. So, you know, where we're really trying to lay focus is ensure developers to continue to use Quarkus, it's still the, you know, the dominant language for enterprise development. You still get the benefits of these new architectures, so ensuring that Java continues to be you know, performant and efficient in these new you know, constrained environments. >> Okay, excellent, so we're not calling it cloud native Java though, right Rich? But we are bringing, if I heard right, Java for things like containers Kubernetes, I even heard functions as a service so, we're talking to server lists of you know, open shift server lists something that's being talked about this week. So help us understand you know, if Java was long in the tooth. You know, what stays the same, what's different, how have people been managing and you know building applications in this environment, because obviously you know, we've been dealing with containers for a number of years now, so what have they been doing so far and, you know, why is Quarkus different from some of the alternatives that are out there. >> Really, the goal is to introduce those that stayed the same. It's not a different language, it's not a fork. It is Java, you're writing Java applications, essentially in the same way you used to write them. And you may be using Microsoft still functions so slight difference in terms of design, but it's, you know, we want to ensure that you can bring your favorite frameworks and wipers with you as well. When you're accessing databases or message brokers. We want to ensure you can still use those technologies so we're trying to bring the whole ecosystem with us, with Quarkus, so those things can run well, in a you know, container or service environment as well. And that's super important because the real benefit here is any organizations face the choice of I want to develop cloud native, I want to develop functions, but I've got this huge investment in Java in terms of skills and you know, tools and tool trains and I don't want to go learn a new language, just because I need to you know, take advantage of things new environments so we're essentially giving developers their cake and allowing them to eat it. We are trying to provide the best of both worlds. Stick with the language you already know and you know, have lots of experience with, and still be able to get the benefits of running in our containerized environment. >> Okay. what are some of the challenges here, so you know from an infrastructure standpoint. My background is, you know, virtualization broke a lot of pieces and containerization does the same thing. As you mentioned, things you know, spin up really fast and they don't stay on nearly as long. You know, god, you mentioned functions as a service, often we're measuring things in milliseconds, so everything genomes, understand what's up how do I manage it, how do I monitor it all of those pieces so, you know, I understand you're saying we take the skill set and what we know. But, you know, there's got to be some on ramp here and some considerations >> Yes, so, yeah, absolutely so, Red has taken on the ramp and ensuring that this ecosystem moves with us. We do a lot of hard work within Quarkus, so developers don't have to. We do some very, very clever stuff that very few organizations, would be able to do because they don't have the depth of knowledge of the Java virtual machine that we do. We're able to take a lot of things that you'd normally start off once only, like loading classes and you know, building kind of memory data around, all the kind of reading configurations all of the things applications do once and only once. Why do it another time? Why not build that into the component time, you're going to do it once but take it out of your runtime environment completely, so there are many ways where we're having to kind of rethink the way you know, applications run. We have to do a reset on what job was built for this environment of long running applications where, if the application took 10 minutes to load up all the stage area and classes and config, it didn't really matter, because it's not going to run for 36 months. You got to do a resale on those design decisions and think very very differently and given with our deep experience with containers and you know, working on things like native, serverless and on deep, deep roots in Java, we were able to do that and really think differently. So, Quarkus takes a lot of that kind of work away from developers they don't have to think too much about it. And by and large, what they can do is focus on their applications and their micro services and read all of that wiring and optimization for them. And hopefully deliver some you know, real significant improvements both in development productivity, but also the kind of runtime resource utilization as well to really lower costs. >> Okay, and Rich, what's is great that's been really the nirvana when you talk about developers is they don't want to have to think about some of that underlying you know, gobbledygook. That was why you know, the term serverless is so polarizing is because from a developer standpoint I don't think about this but everybody screams, but there are servers and there is networking and there's you know, things underneath that I need to think about. So, what is the underlying assumption here. We talked about you know, containers, Kubernetes, functions as a service, what integration is done there? Does this live across? Is it kind of like, you know, does it sit just just on RHEL and therefore everywhere the RHEL lives it's there? Or, help me understand kind of what that underlying you know, substrate is. >> Yeah, right now our focus is RHEL x86, 'cause that's kind of the dominant platform in a cloud. It is just Java, some have that natural kind of portability and you know, as other architectures become important, we can certainly look at those as well. The reason why the underlying machine architecture is important, is because one of the options you have with Quarkus is actually the ability to compile everything down to a binary executable, right? That may give you some additional footprint reduction and performance enhancements. And also if we compile down to native, we do need to think about the underlying operating system and the architecture. But by and large, as a developer you really don't have to care. Just like to you don't have to care with Java today. You also have the option with Quarkus, to run on conventional JVM, open JDK is our preference and if you can run on open JDK, then you can pretty much run anywhere. Under you know, different reasons for compiling down a native, this is running on a traditional JDK, different optimizations, different trade-offs that you'd like to make. >> All right, so Rich, an open source project here, can you tell us a little bit about you know, who's contributed to this, you know, what general adoption is this, and, you know, where are we with the solution today. Is it today ready for production environments? >> Yeah, it's getting close to production ready, yeah, we'll be making this Germany available and during Summit and many of the components we use are tried and tested, again we're not reinventing everything from the ground up. We leverage things like REHL VM, we leverage open JDK, we leverage all our frameworks and library, the developer that are familiar with, we just have to optimize them for Quarkus, so, yeah, much of this is not brand new technology. The existing technology that has that kind of maturity and tolling support. So yeah, we're confident it's production ready. One of the early stages of the development of Quarkus, was to use some of Red Hats own products as goody picks. Actually, you know, optimize those products for containerized environments by rebuilding them on top of Quarkus and that gave us obviously a lot of insight into the general readiness, yeah, the whole kind of eating around and dog food principle. In terms of the organizations in investing Quarkus, you know, we have this kind of have old addedge, we often use at Red Hat, which is you know, if you want to, if you want to move quickly, go alone. If you want to go far, then go with others. We're at a stage, where we've been developing Quarkus very, very rapidly and that's mostly been a Red Hat effort. We've certainly got some help from the mothership IBM and I expect that to be an increase overtime and we're now in a point where we have a Germany available product coming up and we're ready to really kind of expand the ecosystem. So, we're looking for you, whether you're a framework provider, you've written a framework for Java and you want to have that Quarkus provider, ensure that runs really well and partly the kind of growing ecosystem around Quarkus, we're looking for that, we're for, you know, cloud providers to you know, take this technology and see how it runs in other environments and give us feedback. So, yeah, definitely looking to expand that ecosystem of contributors, so we can really turn this into kind of the facto technology for the cloud. >> So, Richard, stop back for us for a second, you've got a long history with Java. You know, why in 2020 is you know, Java still, I believe it's like number two on the language list there. Why is it so important today and why is moving forward to all of these cloud solutions so important for that ecosystem. >> Yeah, I think it comes down to you know, organizations are faced with a tough choice. That they stick with the language that they know and love, which is Java, the language, the relevant applications for the last decade and not be able to take the best advantage of cloud and native or serverless environment. Whereas if they go and learn a new language, Datalog or No.js and you know, kind of hunt around and trying to see if that has the same kind of ecosystem and support. So, we want give organizations a better choice, which is you can stick with a language you already know and love and you have skills and the resources, yeah, you can still take advantage of these new environments and that's you know, I'm mean, fundaments the problem we're trying to solve for your customers. That twice open source projects are, they live or die, depending on, they really do scratch an itch, you know, fulfill a need with real developments. I'm going to think we've certainly from the adoption and interest we've seen with Quarkus, we really do think we've found a very real problem to solve. >> Yeah, Rich, before we wrap up, I just want to give you the opportunity, you know, how is your teams doing, I think you know, Red Hat's making a real concerted effort to make you know, an appropriate tone for the event this week. Trying to make sure it's not you know, some of the usual glam that we normally expect to see, full on the community all together, but, you know, the community is so important and you know, the network of people that, you know, built not only you know, technologies but also careers and you know, relationships, so, give us a insight as to how your teams doing, everybody in these challenging times. >> I think this is another good example of where open source really does show it's resilience. Open source projects are simply very, very distributed. No open source projects rely on an office being open, so your word distributed team all used to work using distributed tools across the world, different time zones. It's kind of natural for us, so we're kind of plugging on, you know, just as we have them in the task, you have a few more dogs in the background and crying babies and you know, we're all humans, we all tolerate that. We have great support from our leaderships, that's Red Hat and IMB. They're very clear that they've got people and families before revenue and that's good to know. Everybody's you know continuing as they can to you know, ensure that we have you know, great technology out there 'cause like I said there's real demand here that needs to filled and we're going to continue doing that. So, yeah, everybody's kind of holding up pretty well, so, let's just see how long this thing goes but again, I do think it is a valuable kind of lesson on the resilience of distributed teams and open source in particular. So, yeah. >> All right, well thank you for that Rich. Just to bring it on home, as you said, the general availability of Quarkus you know, is in front of us here, really expecting the ecosystem in costumers move. Give us a little bit of what we should be looking at going forward, what are some of the kind of maturity steps and what should we expect to see, through the remainder of 2020. >> Yeah, it's going to be a pretty exciting year, I mean, given the changes we were all going through we are going to try and come meet developers, where they are, which is you know, on their laptops and in front of their computers, so, we're going to do, we're playing through a bunch of you know, kind of very quick webinars, you know, quick bye what it takes, you know, interesting features, we're going to do some virtual hackathons as well, so you can actually get people with time and talk with some experts. We have platform for doing that. So, we're pretty excited, we, you know, again with the incident, we can reach a lot of developers very easily. Actually far more than we could at a live even like Summit, so, we're going to make the best of it and try to get at to as many developers as we can with Quarkus and you know, hopefully they'll repay us by investing a little bit of time into it and giving us some feedback and you know, trying some applications and you know, see how it goes. >> All right and you know, final, final question for your Rich, you know, Quarkus, I have to imagine that the Quark, the subatomic particle, you know, came into the naming there. Is there some connection with that? I guess why the name to the project? >> Yeah, I mean that's pretty much it, you know, the Quarkus you know, kind of. (mumbles) Arguably the smallest fundamental particle. >> And can we find something smaller? >> Well, there potentially is something smaller but that's kind of in the realm of quantum mechanics and physics, which I'm not an expert on, so, but yeah, it's meant to mean small and the us bit, the US bit. I'd like to think there was a really good big meaning around that. The meaning is that we understand, that trying to do any kind of brand leadership or trademark protection on a well know server like Quark, is it possible? So, we had to add something to Quark and Quarkus kind of sounded cool. >> All right, Rich Sharples, pleasure to catch up with you, congrats on the progress for Quarkus, definitely looking forward to watching it's progression in the future. >> Thanks, great talking to you. >> All right, I'm Stu Minneman. Lot's more coverage here at Red Hat Summit 2020. Thank you as always for watching The Cube. (gentle music)

>> Announcer: Live from San Francisco it's theCUBE, covering Red Hat Summit 2018. Brought to you by Red Hat. >> Hey welcome back everyone, this is theCUBE's exclusive of Red Hat Summit 2018, live in San Francisco at the Moscone West, I'm John Furrier the cohost of theCUBE. Here this week, as a cohost analyst John Troyer, co-founder of TechReckoning, an advisory and community development firm. Our next guest is Jim Whitehurst, the president and CEO of Red Hat, we have the man at the helm, the chief of Red Hat. Jim great to see you thanks for coming on and taking the time. >> Yes great to be here, thank you for hosting with us here. >> So you're fresh off the keynote, you've got a spring in your step, you're pumped up. Red Hat is really getting accolades across the board so congratulations on the big bets you've made. >> Jim: Thank you. >> You guys are looking like geniuses. We know you're super smart as a company so congratulations. >> Either that or lucky, but we'll take it either way. We are well positioned. >> Analysts love your opportunity, we're reading in the financial analysts out in the web it's saying, you know, the expanded market opportunity for Red Hat is looking really good. You've got infrastructure applications and management all kind of come in together. OpenShift is a center piece of all this and the cloud scale world is moving right to your doorstep. This is really the big tailwind for you guys. By design or like, how does that all coming together, is it the master plan? >> Well yeah I think it's two things, one is because we don't bet five years out on technology and write a technology stack to get there. That's not our model. Our model is to engage in communities, and when those communities get popular enough that we think that there's value in a supported version, then we offer the supported version. Now if you flip that around and think about what that means, it means we're never wrong with the technology bet, because we're not providing a product until it's something that's already highly successful. So we didn't offer OpenStack until it was successful. We weren't offering a Kubernetes offering until it was popular, and so I think that's one benefit. We truly work bottom up in communities. And then secondly I do think we've benefited from the fact that we've lived in the old traditional enterprise world for 20 years helping them migrate from Unix to Linux. So I think we understand the old world and the one kind of spin we put on the technologies is we have the sense of, okay for traditional enterprises, it's great there's all this cool stuff that Facebook and Twitter and others are doing, how does that apply to this set of problems? I think we uniquely have a foot in both worlds so we work and develop with the Googles, Facebooks, Twitters, but we really think hard about how those technologies apply to a traditional enterprise and the context and legacy migration and all the other issues that they face. >> You had years of experience dealing with the practical nature of getting support to customers. But you got to bring that new shiny new toy but make it right for the customers. >> Yeah exactly, and I think one of the reasons OpenShift, you mentioned that, it's our Kubernetes platform, is getting so much attention is we have instrumented and architected it to be able to run traditional stateful enterprise applications, and so you can do cloud native 12 factor, blah blah blah blah blah on it, but importantly you can run your traditional application suite on it, and so one of the reasons like you see so much momentum and so much interest in it is we're trying to span both worlds, and really thinking from an enterprise IT mindset in terms of their problems and saying how do you apply these technologies to make it work. So we're not sitting here saying you need to go do this, you need to adopt Google's practices. What we're saying is here's great technology we think you can leverage to kind of help you as you migrate to this new world. >> You guys got some clear visibility, and I think it's interesting in the container trend and Kubernetes, really good timing for Red Hat with this going on, and so two things we were commenting on our open today was we got to interoperability of multiple cloud options going on with Kubernetes and containers with respect to legacy applications, and then you got the cloud native scale for all the new stuff. So the old model in tech was kill the old to bring in the new, but now you have a new model where you can actually keep the old legacy, containerize it while building new functionality all within software that you guys are enabling, so this is kind of a breath of fresh air for a lot of people in the industry, on the enterprise side saying oh I can still use my stuff. But yet build new scale with cloud and on-prem and have a choice. >> Exactly. And it's not just use my old stuff. It is also leverage my existing people and their skills. Recognize the appdev world, most people aren't developing in a stateless cloud native way, and if you look at the traditional enterprise developer, they on average have four hours a month to do continuing education and new skill development. So, the idea that you're going to flick a switch and say all my new applications are going to be in this new model is crazy. Plus so much of the work you're doing is around your existing estate, really providing a platform that says you can develop new with the skills once you have those. You can take your existing people and take them on a journey versus like this big chasm that you have to get over as you think about both your applications and skill sets and build over time. I think that resonates really well with enterprises. >> Jim I really liked the keynote this morning. It was a very customer focused, not technology focused, and a lot of these keynotes lately have been fear based. You know, change or die, right? Your company's going to go out of business. You had a more positive vision, and the stories there were very good. A lot about time to market, time to value, some nice stories. I was joking, I think, you know, flying cars would be great, but I know I'm in the future if T-Mobile can help car makers update the apps in the car within a couple months using OpenShift, right? That's the future as far as I'm concerned. But you had this really nice framework of instead of preplanning everything as IT is want to do, you talked about configure, enable, engage. Can you talk a little bit about that framework and kind of your prescription for upleveling the organization and it's resiliency basically, as it hits the ground running. >> Yeah sure, and so I think you put a really good light on this idea of so many technology companies are out there kind of almost fear mongering around digital transformation, and what's happening is organizations around the world, fundamentally how they create value is changing. And it's all gotten listed under this moniker of digital transformation. But what it's basically saying is the future is very unknowable because the world is changing very, very fast, and it's ambiguous. You're likely to have the uberized, I mean that's a word now, orthogonal competitors coming in different ways. So your normal way of let me do a five year plan, let me prescribe a set of initiatives, organizations, and job descriptions to go attack that, and then execution becomes about compliance against that plan. That model no longer works when you don't know the future well enough to be able to do that. And so rather than just pick on that and say oh you should be scared, you should be scared, what we tried to do is say hey, Red Hat's lived in that world forever. Like, we had no idea that Kubernetes was going to be as successful as it is, and we don't necessarily know where it's going to be five years from now. But we know if we build the right context, it will develop the capabilities required for us to meet our customers' needs. And so applying that same model that we've seen in open source, and frankly we see in a lot of web 2.0 companies, we get asked over and over again, hey you provide me great technology, but help me contextualize this broader problem. Because the problem that everybody has is I need to be able to move more quickly, I need to be able to react to change more quickly, and I need to innovate more effectively. That is not a SKU. If that were a SKU we would be $100 billion company, right? That's not a product you can buy, it's a capability to build. And so the model we talked about was planning gets replaced by configuring, right? So, you don't know what the future's going to be but you know it's going to change, and so configure yourself for change. Prescription, or this idea you lay out all the steps that need to happen for people. In an unknowable world you can't do that and it gets replaced by enablement. So how do you enable people with the strategy, the context, but also the tools, decision support tools and information to make the right decision. And execution becomes less about compliance and more about engagement. So how do you engage your people in your organization to effectively react to change going forward? And so this model, and it's a very open sourceish type model of from plan, prescribe, execute, to configure, enable, engage, I think encapsulates a lot of what organizations will need to go do to be successful. >> I got to ask you a question on the community piece. I think that's where you guys have been successful with the community. It's a great way to be successful. You know, AB testing, you just look at what people want and you deliver on it. There's feedback from the community. So I got to ask you, modern open source, as we look forward on this next wave, what is, in your opinion, the key dynamic going on in open source? How is it changing for the better? What are you guys looking at? Because you're seeing a lot of younger people coming in. Open source is a tier one citizen in the world. Everyone knows that now. I mean and when you guys started it was, you know Red Hat and there's an alternative and now you guys have made that market. But now we're looking at another generation, microservices, cloud scale. Open source has become the model. You're seeing a lot more commercializations. Projects maintaining open, some productization going on at the same time. Is there some key changes that you see that people should be aware of or that you guys are watching in how open source has evolved? >> Yeah, so two changes. One kind of a broad role of open source, and then I'll come back then to how it's consumed. You're exactly right. Ten years ago and certainly 15 years ago, open source was about creating lower costs open alternatives to traditional software, right? And that's what we did. You know, Linux looks a lot like Unix, it's just lower cost and more flexible, etc., etc. Over time, though, as the big web 2.0 companies adopted open source as a model, you get this move so more innovation was coming from users than from vendors. So it's like big data, take that as an example. Big data exists not because of open source, it's because a ton of large IT leaders like Google and Facebook and Microsoft and Yahoo, etc., had these big data problems. And rather than going and finding vendors to solve them they solved them themselves. They did it in open source. And so you see this model move from vendor led to user led, and it's just like the industrial revolution. The industrial revolution, the winner's were at the machine tool manufacturers. These people use the machine tools. So I think we'll continue to see this happening where the majority of innovation is happening from users done in an open source way. Now the flip side then is, I think there was a sense 20 years ago and even 10 years ago among the zealots, that it's a big war between open source and proprietary. What we're seeing now, I think developing, you see this with a lot of the partnerships we announced, is open source will be embedded across virtually any technology platform, right? You can't use your phone, you can't get money out of a bank machine, you can't do a search, you can't do any of that stuff without using a lot of open source software. Doesn't mean the whole stack has to be open. Now we're all open and we're advocates for that, but you're seeing Microsoft embrace it, you're seeing IBM embrace, and so broadly I think you will see a larger and larger share of the technology stacks that people use today, be open source, and that'll continue. >> I mean I think the proprietary thing is pretty much a dead horse at this point. I mean, open has always won, open is winning, but also to your point about earlier making decisions in the community, there's a risk management benefit on this user led. You're taking away the risk. There's all kinds of risk management being done for you. There's no longer operational things that cost money, like managing releases. You can actually get great operational benefits as well as risk management for what to do. >> Well exactly, because these platforms, it's not let me look at three vendor solutions and say which one do I think looks the best. You actually can say what are people using at scale, what's worked well? And unless you are a bleeding edge adopter, you actually can get the observations of how people are using it and what's working and what's not. And I'll tell you from a vendor perspective it's great. When we release a product we never say, oh, does the market want this? We're not releasing the product until after the market's already adopted the technology in a community way in a pretty significant way. It's a great day, certainly game changing, I think it's going to be written up as kind of a new dynamic that's going to certainly be referenced in the history books. I want to get your perspective on the going forward basis. I know you guys are a public company so you can't really talk about the numbers, but in looking at some of the financial analysts reports recently on you guys, there's a quote I want to get your reaction to. This analyst said, "Software containers "look to be much larger opportunity than RHEL ever was, "and if Red Hat can become a leader here, "it will set the company up for many years to come. So there's obviously some people saying, obviously the container thing is pretty big. How are you guys talking to the marketplace, both the industry market, financial market, and customers around the containerization opportunity, how does Red Hat look at that? How is you as the CEO talk to that trend? 'Cause I know RHEL. RHEL's got a track record. But now you got containers. What's the order of magnitude? What's the mental model people should take to think about containers? >> So I can answer that in a couple of different ways. So let me start off with the size of the opportunity. So, as applications go from these monolithic services for applications to containerized microservices, that architecture is very, very different. And in the old world you'd have an operating system. And then you'd have a whole set of tool chains and management tools and all of these things to manage these applications, right? Well, in a containerized world you expect the platform to manage that for you, right? And so in the old world, which still exists in this growing force, but in the Linux world we provide the operating system on which the application ran, and then you got different management tools, application performance management, CMBD, all of this stuff that worked around that, right? You expect your platform to do that now, so if you think about the value we have in OpenShift, which is our platform, it's doing that telemetry, it's doing patching, it's doing a lot of the automation that was happening before. So there's a lot more value in the platform. And so like a two socket server running RHEL versus a two socket server running OpenShift, there's like an order magnitude price difference. And our customers aren't looking at it saying, oh my god that's expensive, they're actually looking at it like it's cheap versus the whole sets of tool change and management tools they were doing in the old world. So fundamentally the container platform has a dramatic amount of value. Now then from a Red Hat perspective, and I'll bring up another company, it's a little bit of a competitor, but VMWare did a great job of becoming the default management tool company around a virtualized infrastructure. Well why? Because in the shift from physical to virtual they were there first. And they kind of built a paradigm for managing that. Well in this world going to containers, containers are Linux containers, so we're there first. And so working to drive that paradigm, I think we can be a significant share player in these new container platforms, and honestly if you look out in the market, the clouds have their individual cloud offerings, which are fine. We actually can span all of that. So if you have any hybrid structure at all, we have by far the best solution to address that, and I think analysts are assuming we're going to be successful at a much higher value add and therefore more expensive product. If we get our RHEL share of that, you know it's an order of magnitude larger opportunity. >> And that's the cloud economics in play right there. 'Cause with that scale you're talking about okay, OpenShift's taking on a new role for the multi-cloud, for the large scale, you know horizontally scalable synchronous services that are coming online like microservices. >> Exactly, exactly. >> (sound distorts voice) cloud scale partnership and ecosystem strategy right? Your customers are deploying OpenShift on clouds like Amazon, Google, big partnership with Microsoft announced this week as well as a big IBM partnership. Can you talk a little bit about how Red Hat is approaching that cooperation and competition and what parts you'd like to keep on Red Hat versus where you're going to end up partnering. >> Yeah so, we, when you think about the fact that we sell free software, right? You got to think hard about the value proposition. And one of the value propositions we've always believed in is we create choice for our customers. So running Red Hat Enterprise Linux, we're geeks we can talk about all this value associated with it. For many purchasing departments the value was always, when it comes up for a hardware refresh, I'm not locked into one vendor now. I can bid that out because every vendor works on RHEL. So if my application runs on RHEL, I have unlocked choice at that layer. So that's built into our DNA. It's not just a value our software adds, it's the flexibility we're providing customers. So when we look at these new generation platforms, we really strongly believe we can add a lot of value by abstracting whether you want to run it on premise, on a server, on VMWare, on any of the public clouds. By abstracting those away we're giving our customers choice at the core platform layer. So part one is to make sure OpenShift is a first-class citizen and runs well everywhere. And so for our customers then, you know that your application will run anywhere. For our ISV partners to take IBM for instance, because IBM has announced all of their software running on OpenShift, that can now run wherever OpenShift runs, which is, by the way, everywhere, without IBM having to do a lot of work. So creating this abstraction layer huge benefits for someone like IBM. So you can now run mission critical IBM software anywhere you want to run it via OpenShift. So real value to a partner like that, obviously a value to us as it drives workloads. Now one of the other things that we've seen a lot is that people have gotten used to cloud, is they're really saying, hey I love OpenShift, this is great, but honestly you manage it for me. That's one of the things I like about cloud, so I love the idea of this abstraction layer, but I don't want to have to build my own management or my organization to be able to manage this at scale, so you be my service provider. And so we built that in a small way, so we have OpenShift Dedicated, which is an offering that Red Hat engineers run that runs on Amazon. But we want to make sure our customers had choice and also they could choose other vendors they want to work with and you know, Microsoft has a lot of heritage in enterprises, so this opportunity for enterprise is to be able to run OpenShift at scale on Microsoft, fully managed and supported jointly by Microsoft and Red Hat we think is a really phenomenal offering, 'cause we just don't have the scale to build out the capabilities to even meet the demand that's coming in right now for us to offer a managed service of OpenShift. >> And you guys are also doing some work, just to point out and I want to get your comment on, to help with the licensing issues. I know there's been some announcements where you guys are trying to get some more support for folks who are dealing with some of the licensing issues when expiring and so we had your associate general counsel on talking about some of the, version two, version three, grace periods. What does that mean for customers? What is the internal motivation behind that? Is it just making it easier? >> Well you know, this whole idea of licensing being an impediment to customer success, I just find horribly bothersome in the technology industry. And so we've always tried to strip that out for Red Hat, with our customers, and now trying to say well Red Hat's big enough it can have enough influence broadly. How do we try to be more influential in communities? So certainly nothing in the open source licensing arena, not just for us but for any vendor, gets in the way of customer success. And I think that's so important this idea of the artifact of protecting IP means you create lack of flexibility for your customers. I don't think anybody wanted that to happen, but it's happened. And so anything we can do to kind of tear that down we're working to do. >> Well congratulations on all your success, and I know that when I hear words like defacto standard it gets my attention. You see Kubernetes, role OpenShift's doing. We're envisioning a huge wealth creation of new value creation market coming online pretty quickly. You guys doing a great job. Congratulations on that. >> Thank you, thank you. >> Awesome work. Final question for you, I know you got to roll, but you guys are also growing, I noticed your teams are growing, how do you maintain the Red Hat culture? You get more people coming on working for the company, what's the strategy? Give them the Kool-Aid injection? Do you got to bring them in, assimilate into the open source ethos that you guys built and are expanding? What's the plan of getting all these new employees and new partners on board with the Red Hat way? You hand them the red pill and the blue pill and they better take the red pill. No in all seriousness, it's a high class problem but it's still a problem. You know, we do grow roughly 20% a year. Taking this account even modest attrition, roughly 25% of the people at the end of the year at Red Hat weren't here at the beginning of the year. And so when you think about a culture based company, and I spend a lot of time talking about our source of advantages and capability that's tied up in our culture, that's critical, so from how we think about recruiting over half our employees come from employee referrals, they say nobody knows a Red Hatter like a Red Hatter, to the way we do onboarding, which people laugh, you walk out of onboarding you still don't know how to get a computer, but you have been indoctrinated in the power of open source to the way we do checkups along the way, the way we use video and a whole bunch of things to do that. Because it is critical. It is who we are and what allows us to be successful. >> Do you get a lot of Red Hatters out there who left the company, started companies, they come back in the fold through acquisitions? So that's always a great, great sign and we love what you're doing. I'll say CUBE are open. We love open always is winning and it's the new standard. So congratulations. >> Well thank you for having me. It's great. And I really appreciate you being here, participating in the summit. >> All right, Jim Whitehurst, CEO of Red Hat. We're here in theCUBE, live coverage day two of three days of wall-to-wall coverage. Check out all the coverage on thecube.net, siliconangle.com, and wikibon.com for all the action. I'm John Furrier, John Troyer, more live coverage after this short break. Stay with us, we'll be right back.

>> Announcer: From San Francisco, it's theCUBE. Covering Red Hat Summit 2018. Brought to you by Red Hat. >> Hey, welcome back everyone. This is theCUBE live here in San Francisco at Moscone West Fourth, Red Hat Summit 2018. I'm John Furrier, the co-host of theCUBE with John Troyer, the co-founder of TechReckoning, an advisory firm in the area of open source communities and technology. Our next guest is Cube alumni Dietmar Fauser, head of core platforms and middleware at Amadeus, experienced Red Hatter, event go-er, and practitioner. Great to have you back, great to see you. >> Thank you, good to be here. >> So why are you here, what's going on? Tell us the latest and greatest. What's going on in your world? Obviously, you've been on theCUBE. You go on YouTube, there's a lot of videos on there, you go into great detail on. You been on the Docker journey. You got Red Hat, you got some Oracle. You got a complex environment. You're managing cloud native-like services. Tell us about it. >> We do so, yes, so this time I am here mostly to feed back some experience of concrete implementation out there in the Cloud and on premise so. Paul told me that the theme was mostly hybrid cloud deployments so we have chosen two of our really big applications to explain how concretely this works out with you and when you deploy on the Cloud. >> So you were up on stage this morning in the keynote. I think the scale of your operation maybe raised some eyebrows as well. You're talking about over a trillion transactions. Can you talk a little bit about, talk about your multi-cloud stance and what you showed this morning. >> Okay, so first to frame a bit of the trillion transactions. It's not traditional data based transactions. It's individual data access and highly in-memory cached environment. So I'd say that's a very large number and it's a significant challenge to produce this system. So we're talking about like more than 100,000 core deployments of this applications so. Response time matters extremely in this game because at the end what we are talking here about is the back end that powers large P2C sites, like Kayak, some major search engines, online travel agencies. So it just has to respond in a very fast way. Which pushed us to deploy the solutions very close to where the transactions are really originating to avoid our historical data centers in Germany. We just want to take out the back and forth travel under the Atlantic basically to create a better end user experience at the end. >> Furrier: So you had to drive performance big time? >> We, very much. It's either performance or higher availability or both actually. >> This is a true hybrid cloud, right? You're on prem, you're in AWS, and you're in Google Cloud. So could you talk a little bit about that? All powered by OpenShift. >> OpenShift is the common denominator of the solutions. Some of our core design goals is to build the applications in a platform agnostic way. So an application should not know what's its deployment topology, what's the underlying infrastructure. Which is why I believe that platforms like OpenShift and Kubernetes underneath are so important, because they take over the role of a traditional operating system, but at a larger scale. Either in big Cloud deployments or on premise, but the span of operations that you get with these environments is just like an OS but on a bigger scale. It's not a surprise that people talked about this like a data center operating system for a while. We use it this way so OpenShift is clearly the masterpiece, I would say of the deployment. >> That's the key though, I think, thinking about it as an operating system or an operating environment is the kind of the architectural mindset that you have to be in. Because you've got to look at these resources and connections, link them together. You've got all these team systems constant. So you've got to be a systems person kind of design. How does someone get there that may or may not have traditional systems experience? Like us surly generation systems folks have gone through. Because you have devops automating away things. You have more of an SRE model that Google's talking about. Talking about large scale, it's not a data center anymore, it's an operating environment. How do people get there? What's your recommendation, how do I learn more. What do I do to deploy architecturally? >> That's a key question I think. I think there were two sections to your question, how to get there, so. I think at Amadeus we are pretty good at catching early big trends in the industry. We are very close to large engineering houses like Google and Facebook and others like Red Hat of course and so, it was pretty quickly clear to us, at least to a small amount of these decision-makers that the combination of Red Hat and Google was kind of, a game-changing event, which is why we went there, so. It's, I mean. >> Furrier: The containers have been important for you guys. >> Containers were coming along, so, when this happened Docker became big, our development teams, they wanted to do containers. It was not something that the management has had to push for, it was grassroots type of adoption here. So different pieces fed together that gave us some form of certainty, or a belief that these platforms would be around for a decade to come. >> Developers love Kubernetes, and I mean that, containers, it's like a fish to water, it's just natural. Now talk about Kubernetes now, OpenShift made a bet with Kubernetes, obviously, a few years ago. People were like, what is that about? Now it's obvious why. How are you looking at the Kubernetes trade, obviously it creates a de facto capability, you can wrap services around it, there's a notion of service meshes coming, Istio is the hottest product in the Linux Foundation, CNCF, KubeFlow is right behind it, I mean these are kind of thinking about service and micro-services and workload management. How do you view that, what's your opinion on that direction? >> I'm afraid there is no simple answer to this, because if you start new solutions from scratch, going directly to Kubernetes, OpenShift is the natural way. Now the big thing in large corporations is we all have legacy applications, whatever we call legacy applications, in our case these are pretty large C++ environments that are relatively modern but they are not strictly micro-service based and they are a bit fatter, they have an enterprise service bus on top of this, and so it's not, and we have very awkward, old network protocols, so going straight to the mesh for these applications and micro-services is not a possibility because there is significant re-engineering needed in our own applications before we believe it makes sense to throw them onto a container platform. We could stick all of this in a container but you have to wonder whether you get the benefit you really want to. >> Furrier: Time ROI, return on investment, on the engineering, retrofitting it for service mesh. >> Yes, I mean, the interesting thing is Kubernetes or not, we would have touched these applications anyway to cut them into more manageable pieces. We call this compartmentalization. Other people may call this micro-service-ification, or however we want to call this. So that's, to me this is work that is independent from the cloud strategy in itself. Some of our applications, to move faster, we have decided to put them more or less as they are onto OpenShift, others we take some more time to say, okay let's do the engineering homework first so that we reap the full benefits of this platform, and the benefit really is, what is fundamental for developers, efficiency and agility is that you have relatively small, independent load sets, so that you can quickly load small pieces, you can roll them in. >> Time to production, time from developer to production. >> But also quality, the less isolated, the more you isolate the changes, the less you run the risk that a change is cross-impacting things that are in the same delivery basically. It's a lot about, smaller chunks of software that are managed and for this obviously a micro-service platform is absolutely ideal. So it helps us to push the spirit of the company in this direction, no more monolithical applications, fast daily loads. >> Morale's higher, people happy. >> Well, it's a long journey, so some are happy, some are impatient like me to move faster. Some are still a bit reluctant, it's normal in larger organizations. >> Talk about the scale, I'm really interested in your reaction and experience, let's talk about the scale. I think that's a big story. As cloud enables more horizontally scalable applications, the operating aperture is bigger. It's not like managing systems here, it's a little bit bigger picture. How are you guys looking at the operational framework of that, because now you're essentially a site reliable engineering role, that's what Google talks, in SRE, but now you're operating but you're still developing code, and you're writing applications. So, talk about that dynamic and how you see that playing out going forward. >> So, what we try to do is to separate the platform aspects from the application aspects, so I'm leading the platform engineering unit, including platform operations, so this means that we have the platform SRE role, if you want, so we oversee frontline operations 24 by seven stability of the global system. To me, the game is really about trying to separate and isolate as much as we can from the applications to put it on the platform because we have, like, close to 100 applications running on the platform and if we can fix stuff on the platform for all the applications without being involved in the individual load cycles and waiting for them to integrate some features, we just move much faster. >> You can decouple the application from some core platform features, make them highly cohesive, sounds like an operating system to me. >> It is, and I'll come to the second thought of the SRE a bit later, but currently the big bulk of the work we are doing with OpenShift is now to bring our classical platform stuff under OpenShift. And by classical application, I mean our internal components like security, business rule engines, communication systems, but also the data management side of the house. And I think this is what we're going to witness over the next two or three years, is how can we manage, like, in our case CouchBase, Kafka, all of those things, we want them to be managed as applications under OpenShift with descriptive blueprints, descriptive configurations which means you define the to-be state of a system and you leave OpenShift to ensure that if the to-be state is like, I need 1000 ports for a given application, is violated OpenShift will repair automatically the system. >> That's interesting, you bring up a dynamic that's a trend we're seeing, I want to get your thoughts on this. And it hasn't really been kind of crystallized and yet I haven't heard a good explanation but, the trend seems to be to have many databases. In other words, we're living in a world where there's a database for everything, but not one database. So, like, if I got an application at the edge of the network, it can have its own database, so we shouldn't have to design around a database concept, it should be, concept should still be databases everything, living and growing and managing it. How are, first of all do you believe that, and if so, how do you architect the platform to manage potentially ubiquitous amount of different kinds of databases where the apps are kind of driving their own database role, and working with the core platform. Seems to be an area people are really talking about, because this is where AI shines if you get that right. >> So I agree with you that there are a lot of solutions out there. Sometimes a bit confusing choice, which type of solutions to choose. In our case we have quite a mature, what we call a technical policy, a catalog of technologies that application designers can choose from, so there are several data management stores in there. Traditionally speaking we use Oracle, so Oracle is there and is a good solution for many use cases. We were very early in the Nosql space so we have introduced Couchbase for highly scalable environments, Mongo for more sophisticated objects or operations. We try to educate, or to talk with our application people not to go outside of this. We also use Redis for our platform internal things, so we try to narrow their choices down. >> Stack the databases, what about the glue layer? Any kind of glue layer standards, gluing things together? >> In general we always put an API layer on top of the solutions, so we use our own infrastructure independence layer when we talk to the databases, so we try not to have those native bindings in the application, it's always about disentangling platform aspects from the application. >> So Dietmar, you did talk about this architectural concept, right, of these layers, and you're protecting the application from the platform, what about underneath, right? You're running on multiple clouds. What have been the challenges of, in theory, you know, there's a separation layer there and OpenShift is underneath everything, you've got OpenStack, you've got the public clouds, have there been some challenges operationally in making sure everything runs the same? >> There are multiple challenges, so to start with, the different infrastructures do not behave exactly the same, so just taking something from Google to Amazon, it works in theory but practically speaking the APIs are not exactly the same, so you need to remap the APIs. The underlying behavior is not exactly the same. In general from an application design point of view, and we are pretty used to this anyway because we are distributed systems specialists, but the learning curve comes from the fact that you go to an infrastructure that is, in itself, much less reliable if you look to individual pieces of it. It works fine if you use well the availabilities on concepts and you start with the mindset that you can lose availabilities or even complete regions and take this as a granted, natural event that will happen. If you are in this mindset there aren't so many surprises, OpenShift operates very well with the unreliability of virtual machines. We even contract, in the case of Google, what is called preemptive VM so they get restarted anyway very frequently because they have a different value proposition so if you can run with less reliable stuff you pay less, basically. So if you can take advantage of this, you have another advantage using those. >> Dietmar, it's great to hear your stories, congratulations on your success and all the work you're doing, it's sounds like really cutting-edge and great work. You've been to many Red Hats. What's the revelation this year? What's the big thing that people should know about that's happening in 2018? Is it Kubernetes? What should people pay attention to from your opinion? >> I think we can take Kubernetes now as granted. That's very good news for me and for Amadeus, it was quite a bet at the beginning but we see this now as the de facto standard, and so I think people can now relax and say, okay this is one of the pieces that will be predominant for the decade to come. Usually I'm referring to IT decades, only three years long, not 10 years. >> Okay, and as moving to an operating system environment, I love that analogy. I think it's totally right from the data that we see. We're living in a cloud native world, hybrid cloud on-premise, still true private cloud as Wikibon calls it and really it's an operating system concept architecturally, and IoT is coming fast. It's just going to create more and more data. >> So, what I believe, and what we believe in general at Amadeus is that the next evolution of systems, the big architectural design approach will be to create applications that are much more streaming oriented because it allows to decouple the different computing steps much more. So rather than waiting for a transaction, you subscribe to an event, and any number of processes can subscribe to an event, the producer doesn't have to know who is consuming what, so we go streaming data-centric and massively asynchronous. Which, which, which yields smoother throughput, less hiccups because in transactional systems you always have something that slows down temporarily a little bit, it's very difficult to architect systems with absolute separation of concerns in mind, so sometimes a slowdown of a disk might trigger impacts to other systems. With a streaming and asynchronous approach the systems tend to be much more stable with higher throughput. >> And a lot more scalable. There's the horizontally scalable nature of the cloud, you've got to have the streaming and this architecture in place. This is a fundamental mistake we see with people out there, they don't think like this but then when they hit scale points, it breaks. >> Absolutely, and so, I mean we are a highly transactional shop but many of our use cases already are asynchronous so we go a deep step further on this and we currently work on bringing Kafka massively under OpenShift because we're going to use Kafka to connect data center footprints for all types of data that we have to stream to the application that are out in the public cloud, or on premise basically. >> We should call you professor because this was such a great segment, thanks for sharing an awesome amount of insight on theCube. Thanks for coming on, good to see you again. Dietmar Fauser, head of core platforms and middleware at Amadeus. You know, down and dirty, getting under the hood really at the architecture of scale, high availability, high performance of the systems to be scalable with cloud, obviously open source is powering it, OpenShift and Red Hat. It's theCube bringing you all the power here in San Francisco for Red Hat Summit 2018. I'm John Furrier and John Troyer, we'll be back with more after this short break. (electronic music)

(upbeat techno music) >> Host: Live, from Boston Massachusetts, it's the Cube, covering Red Hat Summit 2017, brought to you by Red Hat. >> Welcome to day two of the Red Hat Summit here in beautiful Boston, Massachusetts. I'm your host, Rebecca Knight, with my co-host, Stu Miniman. We are welcoming Jim Whitehurst, who is the president and CEO of Red Hat. Thanks so much for taking the time to sit down with us. >> Thanks, it's great to be here. >> So, I want to talk about the theme of this year's conference, which is celebrating the impact of the individual. In your keynote you talked about the goal of leadership today is to create a context for the individual to try, to modify, to fail, to just keep going. Sounds great. How do you do that? >> Well that's why I say, leadership is about creating a context for that to happen. So you have to create a safe environment for people to try and fail. And you know, this is a tough one, because somebody fails 20 times, you know, maybe it's time him to find a new career. >> Rebecca: (laughs) >> But, you have to create the opportunity for people to fail in a safe way and actually then learn from that. And one of the things I talk a lot about, especially CEOs and CIOs is, you got to create that context. The world that we used to live in was all about taking variance out, you know, Lean Six Sigma process. Innovation's all about injecting variance in, and there's no way to inject variance in without making errors. So how do you, I want to say reward making errors, but you certainly want to reward risk taking and recognize, by definition, some risks aren't going to play out. And that's all about culture. Yeah, it's about process and reward systems, but it's mainly about culture. >> So reward, risk taking, no blaming, what are some other defining elements of this culture in which individuals can feel free to take risks? >> Well, I think a big part of it is you have to celebrate the people who try things And you celebrate taking the risk. You don't necessarily celebrate the successes, right? It's like, you know, in school, you miss something, that's bad, you get something right, that's good. Well we have a tendency to say, let's celebrate the successes, versus actually celebrating the risk taking. And so, there are some processes and systems you have to put in place. You have to have systems in place to make sure no one can risk 100 million dollars. If every Red Hatter could risk 100 million dollars, we'd be in trouble. But you have to figure out how you give enough latitude, enough free time. And, I was just yesterday talking to some Red Hatters who had moved over from IBM. They said, "It's great, we can try new things." Now, try new things within a context of a certain amount of budget or a certain amount of time. So there are processes and systems you have to put in place, but ultimately it's culture more than anything else. It trumps anything else. >> Jim, in your keynote, you said, planning is dead, and that, you know, we're lousy predictors, things are changing so fast. Your role though, you're CEO of a public company that has 60 quarters of consecutive revenue growth. So, it seems you guys are doing pretty well at getting involved in some of the waves that are happening, understanding how to keep growing at a steady pace. Maybe you can reconcile that a little bit for us, as to how you're doing that. >> Yeah, so, one of the reasons that I think that we've been able to navigate a whole set of fairly significant transitions in technology is that we don't select technology, we select communities. And I think that's a really important subtlety. So, we didn't come in and say, "Oh, we like OpenStack more than we like CloudStack of Eucalyptus or the other opensource IaaS that were out five years ago. We looked and observed that OpenStack had built the biggest user base. You know the reason we're significantly involved in Kubernetes today, versus Diego, or Swarm, or the other orchestrators for containers out there, is we observed it was building the biggest community. And, we don't just glom on, we actually kind of get in and contribute ourselves. But we look more to say what are the best communities and let's get involved in that. I don't know what the Kubernetes roadmap is for the next five years, but I'm confident that it has the best community that will drive the right direction for-- >> It's probably a little over-simplified to say you looked for the VHS ecosystem versus the Betamax best technology. >> Rachael: (laughs) >> No, exactly. Exactly, but that's what we think we're good at is observing when a community is the best community. And I say that, it's not just a matter of observation. Whether it's OpenStack or Kubernetes, we get in a help think about governance, right? So, one of the things I think really helped OpenStack is we saw it had the best user community, but we help put together the governance structure, which truly made it neutral, made it open. And so, we try to actually help in doing that, but it really is about identifying communities rather than technologies. >> Is it ever possible that you could identify the right community that might have certain elements, but it's got elements that wouldn't quite work for the opensource way, can you change that community? Is it possible to go in and push a new culture into that community? >> We think we're actually pretty good at that. Now, I think there's a mix of not every community has to be the same. We often talk about, there is no opensource community. There are are literally two million open source communities. And Linux has a culture, many of our projects in JBoss. So Drools is different than Fuse that's different than others. And so, it's okay that the cultures can be different. The key is they all have to have a common element about being open, and committing to being open, and truly being a meritocracy, cause if they best ideas don't win, that's when communities fall apart. And that's actually one of the biggest places where they fall apart. So, I do think we can influence open, and I think just by our contributions we probably influence the cultures of some of those communities. But we don't try to say is there's a Red Hat way to do community. There are a lot of different ways. >> Jim, we look at the cloud space, open is one of these terms that doesn't necessarily mesh with your definition with what the cloud guys do. You guys, of course, supported Red Hat Linux in every single cloud environment that I can think of. For many years you have a expanded partnership with AWS. But, I was debating with Sam Ramji yesterday, from Google, about like, there is no open cloud. There are clouds that use opensource, opensource can live here, but all the big public clouds are built on their platforms and openness is a challenge there. What's your thought as to how you fit there? And then we'll want to get into some of the discussion of the AWS announcement. >> Yeah, sure. So, in defense of the public clouds, it's impossible to offer a physical offering that has hardware in a software stack without it having some of your technologies that don't make it totally open, right? Or transferable. >> Is this why we never saw a Red Hat Open Cloud? >> Well, it's just that, yeah, it doesn't quite make sense in our context for that reason as well. So the role we try to play is, we do try to play the abstracter role, and we do that at multiple levels. So, Red Hat Enterprise Linux runs across a physical data center, virtual data center, and the major clouds. And that's an abstraction point that we think adds value. Because all the way back to 15 years ago, Red Hat Enterprise Linux meant that you could run the same application on a Dell server or an IBM, or an HP Blade, right? And so, we're working to apply that at the cloud level, certainly at the operating system level, but, because of all the services and the growth containers, we needed to do it at another level, and that's what we're doing with OpenShift. So, OpenShift allows you to run on physical, or on virtual in your own data center, on the major public clouds, and take advantages of the services underneath, but do it in a little bit more of an abstracted way. >> All right. So, we had Optum on yesterday, who was also part of the keynote. He's using OpenShift. He's using AWS. He was very excited about the opportunity of OpenShift being able to extend those Amazon services. You and Andy Jassy doing a video this morning. Give us a little bit of the inside look. You know, how long did it take to put this together? My understanding, it's not shipping today, but coming a little bit later this year. Give us a little bit behind what happened. >> Yeah, so. You know, this really started off with a breakfast Andy and I had in January, where we said, look, our teams are working really well together, and we've been partners since 2008, but kind of from the bottom up, I think we were taking very much an incremental approach of what we could do together, what customers we could work with. And, I think it's a little bit in the context of they've been out some other kind of big deals with some other vendors, and so, why don't we think about, what's a true net new offering. So let's now just talk about, oh, running it on Amazon's lower cost. I mean, clearly there's a cost thing there, but, what can we do that's like, wow, actually changes the life of some of the people who are using our technologies. And so what we decided is, well, wouldn't it be amazing, literally at breakfast we were talking about it, if OpenShift, which is used by enterprises all around the world, could actually leverage the thousands of services that AWS is putting out, right? So, right now, if you want to use all of these services, you have to be on AWS, which is great, but there are a lot of customers for whatever reasons, for regulatory reasons, or just by choice or economics, who decided to run on-premise or elsewhere. And so, by making those thousands of services available, it's a win-win all around. For Amazon, it's a ability to expose some really amazing innovation to many, many thousands, hundreds of thousands of developers, and for us it's a way to expose all this innovation to our developers, without kind of forcing someone necessarily to go all-in on cloud. Now, I'll say that we were literally, you know, Sunday night still getting the final contract done. >> Rebecca: (laughing) >> But I would say, when you have a really clear, differentiated source of value for customers, the deal came together, I think, relatively quickly. >> Yeah, et cetera. One of the things we've been trying to reconcile a little bit is, when you talk to customers about where their applications live, that hybrid or multi-cloud world, versus the offerings that are out there, it was a mismatch, because, you know, they were like, oh, I'm using VMware in one place, and I'm using Amazon somewhere else. I've got my SaaS in a different place. We're starting to see Amazon mature their discussion of hybrid through partnerships of yours. OpenShift looks like something that can really help enable customers to kind of get their arms around those environments in many locations. >> Well, I think so. One of the things, if you really go and talk to developers, developers really don't care that much about infrastructure software, and they shouldn't care. And, it's interesting. I think developers right now are really enamored by containers, because containers somewhat makes their life easy. But, I was talking to some of the folks in Red Hat that deal a lot with developers, and they say, ultimately developers shouldn't want to care and don't want to care about even containers. They just want to write code, and they want code to work, right? And one of the cool things about OpenShift is that's kind of what you're doing, is you're saying write code. Yeah, use any of the services you want from anywhere you want to use it. They're all there. They're all available. You don't have to worry about, I want this service, so I have to run this on Amazon, or, hey, I got my database on-premise, so I got to run here. Let's just make it easy. And I think that's one of the cool things about this announcement that's cool for developers, but it's also unique that it's something that only we could bring together. >> Yeah, serverless is something that's been gaining a lot of buzz to kind of say, right, it's underneath there. There's probably going to be containers, but my people writing applications don't want to worry about that. Speak to, it's the application affinity and that tie to kind of modernization of applications that seems to be one of the biggest challenges we've been facing for the last couple of years. Why are companies coming to Red Hat, working across your solution set to help them with that challenge of their older applications, but also kind of building the new businesses. >> Well I think for a couple reasons. So first off, if we really think about what Red Hat is, we call ourselves a software company, but we give away all our IP, so that's a stretch, right? >> Rebecca: (laughs) >> You know, when we think about our overall mission is, we think, there's enterprise customers here with a set of challenges, and there's all this phenomenal innovation happening in opensource communities. How do we build a bridge between those. So certainly that's product. So we create opensource, well, products out of opensource projects. It's about architecture, and then it's about process. And we talked about open innovation labs. But in part of thinking about that's what we do, we obviously start off say, well, what are enterprise problems, and what are technologies that help solve those problems? So, one of the things that we've driven so hard into our container platform is the ability to run stateful applications, right? So it's great to talk about scale-out and cloud native, and we certainly do that, but go talk to any CIO and 99.9% of their application portfolio is stateful. And so, we think about that and we drive those needs. And the reason we're the second largest contributor of Kubernetes isn't just because we're nice people. It's because we're trying to drive enterprise needs into these projects. And so, I do think that technologies that would ultimately emerge, and the products we're able to put out, help enterprises consume opensource in a way that is actually value adding. >> I wanted to ask you about the examples that you used in the keynote today. The three that you highlighted were governance. >> Jim: Yeah. >> And I think that that was really interesting because you're showing how opensource is bringing new innovations and ideas into government and agencies not necessarily known for innovation. Where do you see the future of technology in government coming together? >> Well, one of the reasons I wanted to use government examples is that I actually wanted to highlight, well, what's the role of government when you start thinking about innovation. So, certainly, we could've brought up a lot of examples. You know, yesterday the Optum folks that are big users of our platform, and they've kind of created a context for innovation among their developers. But the reason I wanted to highlight governments, and really try to do it from regions around the world, was to say there is a role for government when you start thinking about what is the new system underneath the economy. So, in the 1940s and 50s in the US the interstate highway system was an important piece of infrastructure. We've always thought about roads and bridges and airports as important for creating the underpinnings for an economy, and that's really, really important in a world of physical goods. And it's not that we don't have physical goods now, but more and more we still have to start thinking about information assets. And look, I've gone and seen the FCC and advocated for net neutrality and all that stuff. And so, certainly broadband as a fundamental infrastructure's important, but I think that government plays a more important role. Whether that's education, and we could spend two hours on education, but even kind of creating these contexts where you make data available. That's what I loved about the British-Columbia example. But broadly it's like, how do you create a context for more citizen participation. I think it's just as important in the 21st Century as roads and bridges were in the 20th Century. >> Jim, you mentioned net neutrality. I'm curious your take on just kind of the global discussion that's going on. A lot of your customers here are international, you've got open communities. The question about net neutrality, trade. It feels like many people, we interviews the president of ICANN a few years ago, and was worried about, you know, are we going to have seven internets, not one internet, because there are certain Asian, and even like Germany, worried about cutting things off. How does that impact your thinking? Do you guys get involved in some of those governmental discussions? >> Well we do. A matter of fact, we actually do have, I'd say a small government affairs team that advocates around these issues. Because we see it too, even with OpenShift, where you start saying, well, different privacy laws in Europe versus the US, but what if someone's running OpenShift in Europe, but it's actually instantiated in the US, and who can get access to what data. Those are really, really important issues. And it is a little bit like, you know, we ought to pick the same railroad gauge, right? To some extent, we need to have a set of consistent policies, not necessarily in every area, but enough that you can actually have the free flow of information, without worrying about, oh my god, I'm exposing myself to felony privacy issues because I'm hosting this application on a cloud that happens to be in the US. So there's some real issues that we have to work through. And they're so bleeding edge and so complex, I'm not sure that we're quite ready to get those done. But these are going to be critical, critical to the economy of the 21st Century. >> The other thing, I can't let you go without asking you about just the opensource business models themself. I've been listening to podcasts. We had a couple of companies go IPO recently. >> Jim: Yeah. >> They're better involved, and they're like, oh wait, I'm an enterprise company, I'm a software company. VC, you shouldn't invest in opensource because they can't monetize what they're doing. What's your take on the investment and business prospect for the other companies that are not Red Hat? >> Well, look, I'm thrilled to see Cloudera going public. Obviously Hortonworks public. MuleSoft recently. And I know some of those are hybrid models, they have an open core, and they have some other proprietary around it. But look, it's still dollars that are getting invested in opensource software I think we've clearly proven a model that you can have 100% opensource and build a successful business. For a whole set of technologies, it's clearly a better innovation model. The thing that I continue to push people is, don't think about it as selling IP. And this is, I've actually had conversations with several university presidents about this same issue. University education is more about the content. Don't be scared of MOOCs, right? And most people kind of get that, a university education, yeah, content's a part of it. But there are 50 other things that make up an education. So that's when I always come back to opensource companies and say, assume the content's free, because it's going to be better if it's totally free. And now think about, how do you build a model around the fact that content's free. And, I think education's a great one. Your industry in media is certainly one that needs to continue to innovate around business models as well. So, rather than saying, let's take a development model that's superior in a number of regards for a set of technologies, especially around infrastructure, and say, let's hamper it, and make it work in the old school business model. Let's continue to work to innovate business models that allow the innovation to happen, because it's going to happen, right? You do have to recognize that so much of what you're seeing in opensource is really a byproduct of what Google and Facebook and others are doing. And that's going to continue, so the best innovation's going to come there. You got to figure out business models that work for it. >> You got to figure them out Thank you so much, Jim. Jim Whitehurst, we appreciate your time. >> It's great to be here. Thanks so much for having me. >> I'm Rebecca Knight for Stu Miniman. We will return with more from the Red Hat Summit. (upbeat techno music)