 from San Francisco, it's theCUBE, covering Red Hat Summit 2018, brought to you by Red Hat. Everyone, welcome back to theCUBE's exclusive coverage of Red Hat Summit 2018 live in San Francisco, California at Moscone West. I'm John Furrier, co-host of theCUBE with John Furrier, co-founder of Tech Reckoning, advisory and community development firm. Our next two guests, Mike Peach, vice president and general manager of middleware at Red Hat and Mark Little, vice president of software engineering for middleware at Red Hat. This is the Stack Wars right here. Guys, thanks for coming back. Good to see you guys again. Great to see you here. So we love middleware because Dave Vellante and Stu always talk about the real value is going to be created in the abstraction layers. You're seeing examples of that all over the place with Kubernetes containers, a lot of multi-cloud conversations, workload management, all these things are happening at these really cool abstraction layers. That's obviously getting on global, I'd say middleware, but it's where the action is. So I got to ask you, Supercool that you guys have been leading in there, but the new stuff's happening. So let's just go review last year versus this year. What's different this year? New things happening within the company? We see CoreOS is in there. You guys got OpenShift is humming along beautifully. What's new in the middleware group? There's a few things. I'll take one and then maybe Mike can think of another while I'm speaking. But when we were here this time last year, we were talking about functions of service or serverless. And we had a project of our own called Function with a K. Between then and now, the developer affinity around functions of service has just grown. Lots of people are now using it and starting to use it in production. We did a review of what we were doing back then and looked around at other efforts that were in the market space and we decided that actually we wanted to get involved with a large community of developers and try and move that in a direction that was probably beneficial for everybody, but clearly for ourselves. And we've decided, and we announced this publicly last year, but we now involved with a project called Apache OpenWisk instead of Function. And OpenWisk is a project that IBM originally kicked off. We got involved. It was tied very closely to Cloud Foundry. So one of the first things that we've been doing is making it more Kubernetes native and allowing it to run on OpenShift. And in fact, we were making some announcements this week around our functions of service based on Apache OpenWisk. But that's probably one of the bigger things that's changed in the last 12 months. I would just add to that, that across the rest of the middleware portfolio, which is, as you know, a wide range of different technologies, different products. In our integration area, we've continued to push ahead with containerizing, putting the integration technologies into containers, making it easier to basically connect the different components of applications and different applications to each other together through different integration paradigms, whether it's messaging or more of a bus style. So with our JBossFuse and our AMQ, we've made great progress in continuing to refine how those are sort of invoked and consumed in the OpenShift environment. Fourth coming very shortly, and literally in the next week or two, is our integration platform as a service based on the Fuse and AMQ technologies. In addition, we've continued to charge ahead with our API management solution based on the technology we acquired from ThreeScale a couple of years ago. So that is coming along nicely, being very well adopted by our customers. And then further up the stack on the process automation front. So some of the business process management types of technologies, we've continued to push ahead with containerizing, and that was being higher up the stack and a little bit bigger a scale of technology was a little bit more complex in really setting it up for the containerized world. But we've got our process automation 7.0 release coming out in the next few weeks. And that includes some exciting new technology around case management. So really bringing all of those traditional middleware capabilities forward into the cloud native containerized environment has been, I would say, the most significant focus of our efforts over the last year. Can you contextualize some of that a little bit for us? The OpenShift, obviously a big topic at conversation here. The new thing that everyone's looking at in Kubernetes. But these service layers, these layers it takes to build an app, still necessary. JBoss, a piece of this stack is 17, 18 years old. So can you contextualize it a little bit for people that thinking about, okay, we've got OpenStack on the bottom, we've got OpenShift. Where does the middleware and the business process, how has that had to be modernized and how are people, the Java developers, still fit into the equation? So a lot of that contextualization can actually, if we go back about four or five years, we announced an initiative called XPaaS, which was to essentially take the rich middleware suite of products and capabilities we had and decompose them into independently consumable services. Kind of like what you see when you look at AWS. You know, they've got the simple queuing service, simple messaging service. We have those capabilities, but in the past they were kind of bundled together in an app server, so we worked to pull them apart and allow people to use them independently. So if you wanted transactions or you wanted security, you didn't have to consume the whole app server. You actually had these as independent services. So that was XPaaS. We've continued on that road for the past few years and a lot of those services are now available as part and parcel of OpenShift. And then to kind of get to the developer side of things, then we put language veneers on top of those because we're a Java company, well at least middleware is, but there's a lot more than Java out there. There's a lot of people who like to use Perl or PHP or JavaScript or Go. So we can provide language specific clients for them to interact. So at the end of the day, your JavaScript developer who's using bulletproof, high-performance messaging doesn't need to know that most of it is implemented in Java. It's just a complete opaque box to them in a way. So this is the trend of microservices. This granularity concept of this decomposition, things that you guys are doing, is to line up with what people want. We'll work with services directly. Absolutely, right? To give developers the entire spectrum of granularity, so they can basically architect at a granularity that's appropriate for the given part of their job they're working on. It's not a one-size-fits-all proposition. It's not like throw all the monoliths out and decompose every last workload into its finest-grain possible pieces. I mean, there's a time and a place for ultra-fine granularity and there's also a time and a place to sort of group things together. With the way that we're providing our run times and the reference architectures and the general sort of design paradigm that we're curating and recommending for our customers, it really is all about not just the right tool for the job, but the right granularity for the job. It's really choice too. People can choose and then based on their architecture they can manage it the way they want from a design standpoint. All right, I got to get your guys because certainly we had a great week in Copenhagen last week in Denmark around KubeCon, Kubernetes conference, CloudNativeCon, whatever their culture things. There was a rallying cry around Kubernetes and really the community felt like that Linux moment or that TCPIP moment where people talk about standards but like when we just do something we got to get behind it and then differentiate and provide all kinds of coolness around it. Core de facto standard with Kubernetes is opening up all kinds of new creative license for developers. It's also bringing up an accelerated growth. Istio's right around the corner, Kubeflow right out of the cool stuff and how software's being built. So very cool rallying cry. What is the rallying cry in middleware in your world? Is there a similar impact going on and what is that? Because you guys are certainly affected by this trend. This is how software will be built. It's going to be orchestrated, composed, like granularity options, all kinds of microservices. What's the rallying cry in the middleware? So I think the rallying cry two years ago at Summit we announced something called Micro Profile with IBM, with Tommy Tribe, another app server vendor, Piara and a few quite large Java user groups to try and do something innovative and microservices specific with Enterprise Java. It was incredibly successful but the big elephant in the room who wasn't involved in that was Oracle, who at the time was still controlling Java EE. And a lot of what we do is depend on Java EE, a lot of what other vendors who don't necessarily talk about it do is also dependent on Java EE to one degree or another. Even Pivotal with Spring Boot requires a lot of core services like messaging and transactions that are defined in Java EE. So two years further forward where we are today, we've been working with IBM and Oracle and others and we've actually moved or in process of moving all of Java EE away from the old process, away from a single vendor's control into the Eclipse Foundation. And although that's going to take us a little while longer to do, we've been on that path throughout four or five months. The amount of buzz and interest in the community and from companies big and small who would never have got involved in Java EE in the past is immense. We're seeing new people get involved with the Eclipse Foundation and new companies get involved with the Eclipse Foundation on a daily basis so that they can get in there and start to innovate in enterprise Java in a much more agile and iterative way than they could have done in the past. And I think that's kind of our rallying call because like I said, we're getting lots of vendors, Pivotal's involved, Fujitsu. And the impact of this is going to be what? A lot more innovation, a lot quicker innovation and it's not going to be at the slow speed of standards. It's going to be at the fast upstream open source innovative speed that we see in likes of Kubernetes. And Eclipse has got a good reputation as well. Yeah, but the other significant thing here in addition to the faster innovation is it's a way forward for all of that existing Java expertise, right? It's a way for some of the patterns and some of the knowledge that they have already to be applied in this new world of cloud native, right? So you're not throwing out all that and having to essentially retrain, you know, double digit millions of developers around the world. Yeah, it's instant developer action. And plus Java is a great language. It's the bulldozer of languages. It can move, it can move a lot. That's a lot of heavy lifting. And there's a lot of developers out there. Okay, final question. I know you guys got to go. Thanks for spending the time on theCUBE. Really appreciate it. Certainly very relevant middleware is key to all the action. A lot of glue going on in that layers. What's going on at the show here for you guys? What's hot? What should people pay attention to? What should they look for? I'll give my take. What's hot is any talk to do with middleware. But, but kind of seriously, we have, we do have a lot of good stuff going on with messaging and Kafka. Kafka is really hot at the moment. We just released our own project, which is eventually going to become a product called Strimsy, integrated with OpenShift. So it's Kube native from the get go. It's available now. We're integrating that with OpenWhisk, which we talked about earlier, and also with our own reactive, a sync platform called Vertex. So there's a number of sessions on that. And if I get a chance, I'm hoping to see it in two. So real quick though, I mean streaming isn't important because you talked about clan granularity. People are going to start streaming services with service messages right around the corner. The notion of streaming asynchronously is going to be a huge deal. And tapping into that stream at any point in time and then pulling the plug and doing work based on that. Also real quick, Kubernetes, obviously the momentum's phenomenal in cloud native, but becoming a first-class citizen in the enterprise, still some work to do. Thoughts on that real quick? When you say Kubernetes native, is it coming faster? Is it, will it ever be? Or certainly I think it will be, but. I think this is the year of Kubernetes and of enterprise Kubernetes. I mean, you just look at the phenomenal growth of OpenShift and that in a way speaks directly to this point, right? Mike, what's hot? What are you doing at the show? What should we look at? I'd add to, I certainly would echo the points Mark made. And in addition to that, I would take a look at any session here on API management. Again, within middleware, the three scale technology we acquired is still going gang busters. The customers are loving that, finding it extremely helpful as they start to navigate the complexity of doing essentially distributed computing using containers and microservices. Getting more disciplined about API management is of huge relevance in that world. So that's, that would be the next thing I'd add. Congratulations guys. Finally, the operating system called the cloud is taking over the world. It's basically distributed computer, all connected together. It sounds like. All that stuff we learned in the 80s, right? It's a systems world and the middleware is changing the game. Modern software, construction of applications, all being done in a new way. You're looking at orchestration, server lists, service mesh is all happening in real time. Guys, congratulations on all the work and Red Hat. Be keeping it in the open. Java E coming around the corner as well. Just a cue, bringing it out in the open here in San Francisco. I'm John Furrier with John Troyer. We'll be back with more live coverage after this short break.