 Hi again Red Hat Developers. This is Jason with the Red Hat Developers Project. We're here at day two of Summit 2017 in the Dev Zone with Rich Nass-Genness. He's going to give us a quick tour of JBoss Cloud Native Java App Dev options. All right, I'm Hutt now. Hopefully this mic is working. So again, my name is Rich Nass-Genness. I'm going to give you a quick tour of the JBoss Cloud Native Java App options for developers. So part of the question becomes why are we even talking about this? What's the dilemma that CIOs or just generally in a company, everybody is starting to face? And it always comes down to a question of time and money. What are my resources that are available? What do I have to get done? What we're finding is a lot of the money spent is going into keeping the lights on. How do we keep our current portfolio running in an affordable fashion that makes sense to keep going? There's also the need to not only babysit existing apps so they keep running. How do we keep enhancing those, making them of more value? And then finally, of course, there's going to be the creation of new apps. So let's keep the lights on. Let's keep evolving what we already have. And of course, business moves on, respond to business changes, so we're going to create new applications. That's ultimately what we're looking at here. Now, in the process of looking at how are we going to get there, we've got to ask what do our developers want? And our developers today are faced with just a whole slew of options that are available to them. Where in the past, we might have been focusing on Spring or .NET or Java. I mean, these were very easy choices, Tomcat and so on. Now we're starting to see all different types of options from your... Certainly the traditional programming language that are still in play, I think even C is still the number one development language that's out there. But new things are coming in. You're seeing WISC come up, which is based on the Swift language, which is, of course, associated mostly with Apple development, iOS and so forth. OpenWISC is open part of this open Swift now. So, and then you've got new models that are coming out. We've probably most people listening this are familiar with microservices. Now we're talking about many services because microservices are out of vogue. Reactive programming is coming online. So we've got things like Vertex. You've got Node coming in. Node is very popular. Of course, pioneered through the browser development. But now, we're also looking at taking that JavaScript and Node options and running it on a server, which, of course, is what Node is all about. And then as you start thinking about frameworks, one of the frameworks I'm going to look at, there was Spring and now there's Spring Boot. There was Java E, now there's the concept of Swarm. We've got frameworks that were created in the early cloud days. So you've got the Netflix stack, the OSS stack. But would you go ahead and create those programs the same way today as you did just a short year, two years? Never mind five, 10, 15 years ago what we did with Java E. There's just a slew of options out there. So rather than try to fight the wave, we had, we had Red Hat and specifically in JBoss Middleware are trying to embrace the wave, if you will. So we've announced OpenShift application runtimes. And what this new announcement allows me to discuss today is a broader set of developer options than I could have done last week with you. So I'm still going to go ahead and give much love to Java EE developers and the value that a Java EE stack can bring to the table. There are just numerous uncountable production systems based on Java E that will continue to be there. And I don't want to, I'm going to use an evil parallel here, but it's going to be, Java EE is going to be around for a long time. We still have COBOL systems that are in production these days. There's a long tail to a lot of these applications that we have to take account of. But that said, and I'm going to show you a slide a little bit later that proves that not all EE app servers are built the same. EAP can actually be a very lightweight deployment option. But people are saying, well, lightweight means a lot of different things to me. I'm convinced about lightweight as it may be related to spring boot or maybe wildfire swarm. I want to build something up from the ground up, build me just enough application platform so I can deploy it potentially as a fat jar or we give a hollow jar of instance. We've got a lot of options out there. So that's another model we're going to be supporting as part of OR, what we call OpenShift Application Runtimes, OR is our abbreviation there. So if you want to run swarm with micro profile, we're going to certify and support that. You want to run spring boot in the cloud, we're going to certify and support that plus different technologies. We're going to teach spring how to be Kubernetes aware. We're going to go ahead and start doing things like in our data grid online. We're going to start bringing select redhead technologies to bear to work specifically with spring boot. And it's all going to run on the OpenShift platform. So this is another runtime that you could consider. If you want to start looking at reactive programming, the upstream project we had for reactive programming in VertX, that will be supported as part of OR. If you want to go and do Node.js because you just love JavaScript, you've been doing it, now you want to do it on the server side, that is another runtime we'll be supporting. These are, so rather than have a war over in a debate, and we should debate which runtime is appropriate for what task, but to go to war to say, you know, dump that, use this, that's over. We want to embrace all those runtimes. If reactive makes sense in one case, Java E in another, spring in another, micro profile, I like where things are evolving with the Java world. All of that is now possible. One subscription is our objective. All running one cloud environment, and that would of course would be OpenShift. Okay. And as part of, there's a series of articles you should probably look at on the middleware developer blog out there that dives into each of these options that we're supporting, explaining it. So what's in spring boot? What do we mean by support for history and ribbon and so forth? That's out there. Jboss middleware blog. So I believe it's middleware.developers.com. I think that's the, I believe that's the URL, so. So what we're looking at is a future development state that's going to go out there, and through OpenShift.io, through traditional IDEs, you're going to go through your whole what development cycle makes sense for you? Is it one? Is it a mix? I don't know what it would be. But you go through that whole cycle. Hopefully you're working with pipelines and you're working with OpenShift. When the time comes to go to a runtime, then we're going to shift out of the development tool question and into the question of what is the runtime that's going to be supported in production? That's where the OpenShift application runtime subscription comes important. And again, all those different technologies I talked about will be a combination of certified and supported on there. Now, you may ask, okay, JBoss, as a brand, you have a lot of other products. Why aren't they anore? Well, they're additional services. So if you want to do BPM processes for consistent business processes, that's available for use. You want to have business rules for consistent decision-making, that's available. In-memory data grid, in-memory data storage, that's available. Messaging, OpenShift, OpenShift, I'm sorry, AMQ7, which we just announced, will be running on OpenShift as well. These are the variety of middleware services that will be in support of your applications. So those will all be available, not as run times as middleware services on the cloud. And of course, then we have all the brilliance that's associated with the OpenShift technology itself, and we rely on that. We're not trying to, and we're going to embrace that. So if you look at some of the other offerings out there from middleware, sometimes a middleware offering may want to take over the management of a cloud, make everything look like it's hidden behind. The cloud management should be hidden behind a middleware administration. We're not taking that approach. Certainly, there's ways to peak at what's going on within our application stack, but we really want you to have that full DevOps and management experience through OpenShift to take care and nurturing of the middlewares deployed. Yes, it'll all be part of the same, yes. We just announced Alpha yesterday, so we've got a little time before we get to GA, and that time between Alpha and GA will release more and more details and really get into the full what is certified versus what is supported. Basically, we're going to certify a lot of what we don't own. We can't really support somebody else's products, but we can certify that it will work, and that's what we're interested in. And of course, wonderfully, physical environment, virtual environment, or cloud, which everybody's really more interested in cloud these days. These lightning talks go by really fast. So two more slides I want to talk about. As you're picking your way through what you want to do, it might help to think about use cases, and this is another area we'll be providing some guidance on there. If you will, there's a place in the world for J-Ball CAP versus Wildfly Swarm versus using Tomcat versus using things like reactive programming. We want to, instead of just throwing stuff up on the wall and say you choose, which you're certainly welcome to do, we're going to try to provide a prescriptive path that says if this characteristic is within your organization, you probably want to look at this runtime. It's probably best suited to help solve that problem. The good news is, as you look at all these bubbles, they're all going to be supported. And lastly, because it's just been there, don't think of J-Ball's EAP like you might think about the older IBM WebSphere runtime or the Oracle WebLogic runtime. What is resource intensive beast that's out there just taking up your servers? We actually ran some tests and said, let's take a look at what would the weight be as far as memory usage, memory under load, memory at boot. So give us some realistic things you're doing with a modern microservice. What do I have at the end? And as you can see here, without going through this chart cell by cell, the end result of using AAP in the cloud is that it can be truly a lightweight option for you to go ahead and run microservices. I think the question will become, what is your preference, honestly, if you're creating microservices development and you want to use it, have some Java E, access to Java E features. Do you want a runtime that uses smart module loading, everything's available to it and it figures out what it needs to load based on what the demands are, that's EAP. Or would you rather go out and say, I have my code base, I know what I'm going to use, only build enough of a runtime to match exactly what my code is. That is what swarm is. At the end of the day though, you end up having a runtime that's very efficient, either way, that's running within OpenShift. And that's key. The details, Apache Bench was used to get in all these particular areas. Oh, the actual environment. I'd have to talk to Thomas about that. We can get you that answer though. Yeah, that person is available here at Summits to talk about. So don't fear JBoss EAP in the cloud. It can be very efficient. And with that, I'll ask you to take up the challenge. Try to go out there, take a look at what you need, consider Red Hat not only for your container deployment, but for the various run times that you may be writing your applications on. Take up the challenge, let us know about it. And my 10 minutes is over. Thank you.