>> Voiceover: Live from Boston, Massachusetts, it's the CUBE. Covering your Red Hat Summit 2019. Brought to you by Red Hat. >> And welcome back to our coverage here on the CUBE Red Hat Summit 2019. We're at the BCEC in Beantown, Boston, Massachusetts playing host this week to some 9000 strong attendees, pack keynotes. Just a great three days of programming here and educational sessions. Stu Miniman and I'm John Walls. We're joined by Mike Piech, who's the VP and general manager of Middleware at Red Hat. Mike, good to see you today. >> Great to be back. >> And Mark Little, VP of engineering Middleware at Red Hat. Mark, Good to see you as well, sir. >> You too. >> Yeah. First of, let's just talk about your ideas at the show here. Been here for a few days. As we've seen on the keynote stage, wide variety of first off, announcements and great case studies, great educational sessions. But your impressions of what's going on and some of the announcements we've heard about this week. >> Well, sure. I mean definitely some very big announcements with RHEL 8 and OpenShift 4. So as Middleware we're a little bit more in sort of gorilla mode here while some of the bigger announcements take a lot of the limelight. But nevertheless those announcements and the advances that they represent are very important for us as Middleware. Particularly OpenShift 4 as sort of the next layer up from OpenShift which the developers sort of touch and feel and live and breathe on a daily basis. We are the immediate beneficiaries of much of the advances in OpenShift and so that's something that, we as the Middleware guys sort of make real for the enterprise application developer. >> I'd say, probably for me, building on that in a way, one of the biggest announcements, one of the biggest surprises is gotta be the first keynote where we had Satya from Microsoft on stage with Jim announcing the collaboration that we're doing. I never believed that would ever happen and that's, that's fantastic. Has a benefit for Middleware as well but just for Red Hat as a whole. Who would've thought it? >> John: Who would have thought it, right? Yeah, we actually just had Marco Bill-Peter on and he was talking about, he's like "Look, we've actually had some of our support people up in Redmond now for a couple of years." And we had Chris Wright on earlier and he says "You know, sometimes we got to these shows and you get the big bang announcement. It's like, well, really we're working incrementally along the way and open source you can watch it. Sure sometimes you get the new chipset or there's a new this or that. But you know, it's very very small things." So in the spirit of that, maybe, you know, give us the updates since last time we got together. What's happening in the Middleware space as you said. If we build up the stack, you know, we got RHEL 8, we got OpenShift 4 and you're sitting on top. >> Yeah. Well one aspect that's an event like this makes clear in almost a reverse sort of way. We put a lot of effort particularly in Mark's team in getting to a much more frequent and more incremental release cycle and style, right. So getting away from sort of big bang releases every year, couple of years, to a much more agile incremental again sort of regime of rolling out functionality. Now, one of the downsides of that is that you don't have these big grand product announcements to make a big deal about in the same way as RHEL just did with 8 for example. So we need to rethink how we sort of (Laughs) >> absence the sort of big .0 releases, you know how we sort of batch up interesting news and roll it out at a large event like this. Now one of the things that we have been working on is our application environment narrative. Right now, the whole idea of the story here is that many people talk about Cloud-Native and about having lot's of different capabilities and services in a cloud environment. And as we've sort of gone through the, particularly the last year or so, it's really become apparent from what our customers tell us and from what we really see as the opportunities in the cloud-native world. The value that we bring is engineering all these pieces together, right? So that it's not simply a list of these disparate, disconnected, independent services but rather Middleware in the world of cloud native re-imagined. It is capabilities that when engineered together in the right way they make for this comprehensive, unified, cohesive environment within which our customers can develop applications and run those applications. And for the developer, you get developer productivity and then at runtime, you're getting operational reliability. So there really is a sort of a dual-sided value proposition there. And this notion of Middleware engineered together for the cloud is what the application environment idea is all about. >> Yeah. I'd add kinda one of the things that ties into that which has been big for us at least at summit this year is an effort that we kicked off or we announced two months ago called Quakers and as you all know a lot of what we do within Middleware, within Red Hat is based on Java and Java is still the dominant language in the enterprise but it's been around for 20 years. It developed in a pre-cloud era and that made lots of assumptions on the way in which the Java language and the JVM on which it runs would develop which aren't necessarily that conducive for running, in a cloud environment, a hybrid cloud environment and certainly public cloud environment based on Linux containers and Kubernetes. So, we've been working for a number of years in the upstream open JDK community to try and make Java much more cloud-native itself. And Quakers kind of builds on that. It essentially is what we call a kub-native approach where we optimize all of the Middleware stack upfront to work really really well in Kubernetes and specifically on OpenShift. And it's all Java though, that's the important thing. And now if people look into this they'll find that we're showing performance figures and memory utilization that is on a per with some of the newer languages like Go for instance, very very fast. Typically your boot time has gone from seconds to tens of milliseconds. And people who have seen it demonstrated have literally been blown away cause it allows them to leverage the skills that they've had invested in their employees to learn Java and move to the cloud without telling them "You guys are gonna have to learn a completely new language and start from scratch" >> All right, so Mark, if I get it right cause we've been at the Kubernetes show for a bunch of years but this is, you're looking at kinda the application side of what's happening in those Kubernetes environment >> Mark: Yeah. So many times we've talked about the platforms and the infrastructure down but it's the the art piece on top. Super important. I know down the DevZone people were buzzing around all the Quaker stuff. What else for people that are you know, looking at that kinda cloud-native containerization space? What other areas that they should be looking at when it comes to your space? >> Well, again, tying into the up environment thing, hopefully, you know, you'll have heard of knative and Istio. So knative is, to put it in a quick sentence is essentially an enabler for serverless if you like. It's where we're spinning containers really really quickly based on events. But really any serverless platform lives and dies based on the services in which your business logic can then rely upon. Do I have a messaging service there? Do I have a transaction service or a database service? So, we've been working with, with Google on knative and with Microsoft on knative to ensure that we have a really good story in OpenShift but tying it into our Middleware suite as well. So, many of our Middleware products are now knative enabled if you like. The second thing is, as I mentioned, Istio which is a sidecar approach. I won't go into details on that but again Istio the aim behind that is to remove from the application developer some of the non-functional business logic that they had to put in there like "How do I use a messaging service? How do I secure this endpoint and push it down the infrastructure?" So the security servers, the messaging servers, the cashing servers et cetera. They move out of the business logic and they move into Istio. But from our point of view, it's our security servers that we've been working on for years, it's our transactional servers that we've been working on for years. So, these are bullet-proof implementations that we have just made more cloud-native by embedding them in a way in Istio and like I said, enabling them with knative. >> I think we'd mentioned that Chris Wright was on earlier and one of the things he talked about was, this new data-eccentric focus and how, that's at the core so much of what enterprise is doing these days. The fact that whenever speed is distributed, they are and you've got so many data inputs come in from, so to a unified user trying to get their data the way they wanna see it. You might want it for a totally other reason, right? I'm just curious, how does that influence or how has that influenced your work in terms of making sure that transport goes smoothly? Because you do have so much more to work with in a much more complex environment for multiple uses that are unique, right? >> (Mike) Yeah. >> It's not all the same. >> Huge, huge impact for sure. The whole idea of decomposing an application into a much larger number of much smaller pieces than was done in the past has many benefits probably one of the most significant being the ability to make small changes, small incremental changes and afford a much more trial and error approach to innovation versus more macro-level planning waterfall as they call it. But one of the implications of that is now you have a large number of entities. Whether they be big or small, there's a large number of them running within the estate. And there's the orchestration of them and the interconnection of them for sure but it's a n-squared relationship, right. The more these entities you have, the more potential connections between each of them you have to somehow structure and manage and ensure are being done securely and so on. So that has really driven the need for new ways of tying things together, new ways essentially of integration. It has definitely amplified the need for disciplines, EPI management for example. It has driven a lot of increase demand for an event-driven approach where you're streaming in realtime and distributing events to many receivers and dealing with things asynchronously and not depending on round-trip times for everything to be consistent and so on. So, there's just a myriad of implications there that are very detailed technical-level drive some of the things that we're doing now. >> Yeah, I'll just add that in terms of data itself, you've probably heard this a number of times, data is king. Everything we do is based on data in one way or another, So we as Red Hat as a whole and Middleware specifically, we've had a very strong data strategy for a long time. Just as you've got myriad types of data, you can't assume that one way of storing that data is gonna be right for every type of data that you've got. So, we've worked through the integration efforts on ensuring that no sequel data stores, relational data stores^, in-memory data caching and even the messaging services as a whole is a way of sto^ring data in transit, that allows you to, in some ways it allows you to actually look at it in an event-driven way and make intelligent decisions. So that's a key part of what anybody should do if they are in the enterprise space. That's certainly what we're doing because at the end of the day people are building these apps to use that data. >> Well, gentlemen, I know you have another engagement. We're gonna cut you loose but I do wanna say you're the first guests to get applause. (guests laugh) >> From across all the way there. People at home can't hear but, so congratulations. You've been well received already. >> I think they're clearly tuned in to the renaissance of the job in here. >> Yes. >> Thank you both. >> Thanks for the time. >> Mark: Thanks so much. >> We appreciate that. Back with more, we are watching a Red Hat summer 2019 coverage live on the CUBE. (Upbeat music)

>> Announcer: From San Francisco, it's theCUBE. Covering Red Hat Summit 2018 brought to you by Red Hat. >> Hello everyone and welcome back to see CUBE's exclusive coverage of Red Hat Summit 2018 live in San Francisco, California at Moscone West. I'm John Furrier, your cohost of theCUBE with John Troyer co-founder of Tech Reckoning advisory and community development firm. Our next two guests Mike Piech 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 too. >> So we love Middleware because Dave Vellante and I and Stu always talk about like the real value is going to be created in abstraction layers. You're seeing examples of that all over the place but Kubernetes containers, multi-cloud conversations. Workload management and all these things are happening at these really cool abstraction layers. That's obviously you say global I say middleware but you know it's where the action is. So I got to ask you, super cool that you guys have been leading in there but the new stuff's happening. So let's just go review last year or was it this year? What's different this year, new things happening within the company? We see core OS' 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 as a service or server-less and we had a project of our own called Funktion with a K, between then and now the developer affinity around functions as a 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 actually we wanted to get involved with a large community of developers and try and move that in a direction that was pretty beneficial for everybody but clearly for ourselves. And we've decided, and we announced this publicly last year but we're now involved with a project called Apache OpenWhisk instead of Funktion. And OpenWhisk is a project that IBM originally kicked off. We got involved, it was tied very closely to cloud foundering so one of the first things that we've been doing is making it more Kubernetes native and allowing it to run on OpenShift. In fact we're making some announcements this week around our functions are service based on Apache OpenWhisk. 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 continue to push ahead with containerizing, putting the integration technologies in the 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 Jboss Fuse and our AMQ we've made great progress in continuing to refine how those are invoked and consumed in the Openshift environment. Forthcoming very shortly, 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. 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. 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. >> Go ahead. >> Can you contextualize some of that a little bit for us? The OpenShift obviously a big topic of conversation here. You know the new thing that everyone's looking at and 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, right? So can you contextualize it a little bit for people 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 fitting into the equation? >> Mark: So a lot of that contextualization can actually, if we go back about four or five years, we announced an initiative called Xpass 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. They've got the simple queuing service, simple messaging service. We have those capabilities but in the past they were 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 Xpass. 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. To 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 Pearl or PHP or JavaScript or Go, so we can provide language specific clients for them to interact. At the end of the day, your JavaScript developer who's using bulletproof, high performing 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. >> John F: So this is a trend of microservices, this granularity concept of this decomposition, things that you guys are doing is to line up with what people want, 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 it's finest grain possible pieces. There's a time and a place for ultra-fine granularity and there's also a time and a place to group things together and with the way that we're providing our runtimes and the reference architectures and the general design paradigm that we're sort of 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, I mean people can choose and then based on their architecture they can manage it the way they want from a design standpoint. Alright I got to get your guys' opinion on something. Certainly we had a great week in Copenhagen last week, in Denmark, around CUBECon, Kubernetes conference, Cloud NativeCon, whatever it's called, they're called two things. There was a rallying cry around Kubernetes and really the community felt like that Linix moment or that TCPIP moment where people talk about standards but like when will we just do something? We got to get behind it and then differentiate and provide all kinds of coolness around it. Core defacto stand 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, Cubeflow have the cool stuff on how software's being built. >> Right. >> 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? >> Yeah >> Because you guys are certainly affected by this, this is how software will be built. It's going to be orchestrated, composed, 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 MicroProfile with IBM, with Tomitribe, another apps 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 E and a lot of what we do is dependent on Java E, a lot of what other vendors who don't necessarily talk about it do is also dependent on Java E to one degree or another. Even Pivotal with Springboot requires a lot of core services like messaging and transactions that are defined in Java E. 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 E 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 for about 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 E in the past is immense. We're seeing new people get involved with Eclipse Foundation, and new companies get involved with 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 interesting way than they could have done in the past. I think that's kind of our rallying call because like I said we're getting lots of vendors, Pivotal's involved, Fujitsu. >> John F: 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, the other significant thing here, in addition to the faster innovation is it's a way forward for all of that existing Java expertise, 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. So you're not throwing out all that and having to essentially retrain double digit millions of developers around the world. >> John F: It's instant developer actually and plus Java's a great language, it's the bulldozer of languages, it can move a lot, it does a lot of heavy lifting >> Yep. >> 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 certainly very relevant, middleware is key to the all the action. 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? >> Mark: I'll give my take, what's hot is any talk to do with middleware >> (laughs) Biased. >> But kind of seriously we do have a lot of good stuff going on with messaging and Kafka. Kafka's really hot at the moment. We've just released our own project which is eventually going to become a product called Strimsy, integrated with OpenShift so it's coognative 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 async platform called Vertex, so there's a number of sessions on that and if I get a chance I'm hoping to say into one >> John F: So real quick though I mean streaming is important because you talk about granularity, people are going to start streaming services with service measures right around the corner, the notion of streaming asynchronously is going to be a huge deal >> Absolutely, absolutely. >> Mark: And tapping into that stream at any point in time and then pulling the plug and then doing the work based on that. >> Also real quick, Kubernetes, obviously the momentum is phenomenal in Cloud Native but becoming a first class citizen in the enterprise, still some work to do. Thoughts on that real quick? Would you say Kubernetes's Native, is it coming faster? Will it ever be, certainly I think it will be but. >> I think this is the year of Kubernetes and of enterprise Kubernetes. >> Mike: I mean you just look at the phenomenal growth of OpenShift and that in a way speaks directly to this point >> Mike, what's hot, 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 gangbusters, the customers are loving that, finding it extremely helpful as they start to navigate the complexity of doing essentially distributive computing using containers and microservices, getting more disciplined about API management is of huge relevance in that world, so 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 eighties right (laughs) >> It's a systems world, the middleware is changing the game, modern software construction of Apple cases all being done in a new way, looking at orchestration, server lists, service meshes all happening in real time, guys congratulations on the all the work and Red Hats. Be keeping it in the open, Java E coming around the corner as well, it's theCUBE 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

>> Announcer: Live from Boston Massachusets, it's the Cube. Covering Red Hat Summit 2017, brought to you by Red Hat. >> Welcome back to the Cube's live coverage of Red Hat Summit 2017. I'm Stu Miniman, happy to have two gentlemen from the Middleware group. I have Mark Little who's the vice president of engineering and I have Mike Piech who's the vice president and general manager of the Middleware. Both of you from Red Hat, thank you so much for joining us. >> Mike: Thanks for having us. >> Alright, Mike, let's start with you just before we get into some of the news and everything. Tell us a little bit about your role, how long have you been a Red Hat. >> Yeah, I've been at Red Hat little over four years now. I run the Middleware business unit which comprises product management, product marketing, couple of other ancillary product related functions. We drive a lot of the Middleware strategies, certainly in conjunction with Mark and the engineering team. We also drive a lot of the merger and acquisition activities to sort of extend and build out the business. >> Alright, and Mark, a quick intro, maybe give us a little scope of where your engineering team sits across the globe and what products they're working on. >> So I've been with Red Hat since 2006. Came in with the Jbox Acquisition. I'm also responsible for our mobile and APR management efforts as well as Middleware. We've got an incredibly broad, rich Middleware portfolio and part of what comes with that is a very expensive engineering team which is in I think every single time zone apart from Antarctica. >> Excellent. Mike, let's unpack a little bit. Tell us about the news this week, what's new at Red Hat Summit. >> Probably the biggest news on the Middleware front is our announcement of open shift application runtimes. And really what that is is you can think of it as the next generation of runtimes and really, a next generation embodiment of the functionality that we've all known and loved as the application server. Right, so one of the core elements of the J boss Middleware portfolio from the get-go, the original acquisition of the J Boss company has been the application server, J Boss EAP. Enterprise application platform in Red Hat nomenclature. With open shift application runtimes, we take a lot of that functionality, a lot of that really foundational capability that has been sort of packaged into that entity, the application server and reimagined it, renabled it for the world of microservices, and that's what open shift application runtimes are all about. >> Alright. Mark, maybe you can break this down a little bit for us. I know in other conversations we said "Oh, I hear microservices", sometimes we conflate that with containers so some of the interfaces and challenges for building what you're doing? >> So microservices could be deployed into containers. In fact, you could have containers that have multiple microservices with them. There's a lot of challenges with microservices and as Mike's hinted at, some of those challenges have actually come because we've essentially had to re-architect some of our product lines to be more microservice-y, in a way. Sit well in containers, work well with open shift, so it's important that we don't just think about containers, we actually need to think about containers and orchestration, containers, hence Kubernetes, Which is why we've focused on open shift. And we've spent a lot of time over the last few years re-architecting and broadening our abilities into microservices area and everything we do, particularly in the raw, which is Red Hat open shift application runtimes acronym, is targeted at open shift and we've made a lot of efforts to make our stuff open shift native. >> Yeah, and I'm curious to get both of your opinions. We've talked for years about some of the Cloud Native microservices applications. Feels like there's a little bit more of a spectrum now. What we used to call almost lift and shift, kind of the re-platforming it and then maybe they start breaking up some of the pieces. Start componentizing them. Sounds like containers helps with some of them. What are you hearing from customers? How does that mature the solution set that you're working on? >> Sure. First of all, almost all of our customers are at least talking about microservices. They are all at different phases of their respective trajectories in sort of going down the microservices path. Almost no one would say "Oh, I would never do a microservice." I think most customers are realistic about "Hey, it's not a one size fits all proposition." The microservices approach is really appropriate for certain use cases, certain kinds of workloads, certain kinds of application domains. And in other domains, a less microservices-ish approach might still make sense. In a way, there's not like this hard threshold between what is a microservice and what is a macroservice or something bigger than a microservice. There really is a spectrum of size of modules. The whole idea of microservice is just taking the idea of modularity to another level. Like giving you a finer granularity to work with, but that doesn't necessarily mean that everything should be blown into its minutest possible bits. >> And I would kind of add to that. Some of our competitors, some of the people in the field of microservices often tend to approach this from a completely green field environment where the assumption is that you've got nothing that you need to lift and shift or nothing that you have to bring with you to this new world and that's simply not the case. Nobody has a true green field moment. Everybody's kind of brown field, slightly muddy fields. And I think that's what we've tried to address with what we announced this weekend at the summit. But also, another thing that we're focusing on is not just looking at how we evolve our software, but also how we evolve the people that are developing these things. It's no good us saying to customers, partners, communities "Everything you knew at this point you now have to unlearn and tomorrow morning, when you come to work, you have to have a completely new skillset." People have invested a lot of time and money into themselves, their employees, and they need to be able to take that skillset and evolve it as well. >> Yeah, you've spent a lot of time in the last few years talking about really modernization of what's happening. I've been saying for the last couple of years "The application tends to be the long pole in the tent." So are things starting to move a little faster? What's exciting you and what things have we knocked down and what things do we still need to mature a little bit on? >> Yeah, I would say it is moving noticeably faster. In the last, say, six to 12 months, we've really felt a rapid increase. A year ago, if we had this interview, we certainly would have talked about microservices but there would be a much smaller number of customers who were actively pursuing them. I think part of what happens is once you get some early successes, once you get a few examples out there of "How do you do it? What actually works?" That will start to snowball and bring on other customers who then gain some confidence from having seen it done. To answer the other part of your question, what still remains to be done, I think with our... One of the things that has, I think, continued to... If not be an actual challenge, at least be a perceived challenge in the minds of would-be microservices architects is "How do I manage all this stuff? How do I make dealing with not tens or hundreds but thousands or tens of thousands of these very minutely sized workloads? How do I orchestrate them, how do I scale them, how do I manage them, et cetera?" And that's one of the very challenges that our open shift application runtimes offering that we announced this week is that we meant to address. By putting those runtimes in an open shift native, Kubernetes native environment and automating a lot of that orchestration, taking a lot of that manual labor of dealing with all those pieces off the table, this would make it a lot easier for developers to develop with microservices. >> Mark, I can only imagine how much has changed in the last decade. Containers, the rapid acceleration there. I want to ask you a little bit forward looking, though. What about things like serverless, functions as a service, what's Red Hat's viewpoint on that? How fast do you see that coming? How does that play into your environment? >> So we see it in a way as a natural evolution of microservices. You know, a microservice should be something that does one thing well in a single unit of deployment. A serverless or function is one unit of deployment. So you can see it as another way of doing microservices and we're definitely full in on that. We've been working on projects in Kubernetes and open shift efforts called Function which is our serverless effort and we'll be integrating that with RAW. We think it's a good thing in general. It's obviously not going to be right for everybody. There are some issues with serverless. You may not find it useful for your application. >> Alright, Mike, I want to give you the final word. Speak to customer conversations you're having. What's exciting them in the Middleware space? >> Yeah, I've been really excited in the last 48 hours since the announcement came out. The reaction has been really, really good. I've talked to a number of our large financial services customers, both from here in the U.S. as well as in Europe. I've talked to some other customers in industries outside of financial services. They are unanimous in giving us kudos that we're on the right path, that this is what they wanted and needed to hear. That we are being very forward looking with our Middleware and while we're certainly not abandoning or otherwise letting go of a number of very important workload capabilities that we need to continue supporting in many traditional environments that we really are at the same time taking all of our deep expertise in Middleware and application development platforms and providing the enterprise grade, enterprise trusted, tested next generation runtime foundations for microservices and other emerging styles of development such as Function and serverless. >> Mike Piech, Mark Little, really appreciate the updates on where you are, little bit of visibility towards the future. We'll be turning it over to the Key Note and then back with the last bit of our coverage here, three day coverage of the Cube at Red Hat Summit. I'm Stu Miniman.