 Well, hello and welcome to another Dev Nation. We are here talking to you live from Raleigh, North Carolina. I also have Edson Yanaga sitting in the room with me and he's gonna be answering questions on the chat. So we are live, let your friends and neighbors know that we're live and also remind them, typically refresh your browsers the right way to get back into the session and hear things and see things. Don't use the Q and A tab unless you have a technical question around the way the system works. Put all your real Kubernetes questions into the chat tab. Edson's gonna be answering those in real time as we roll through the presentation. We have a lot of ground to cover today and as you can see on the chat, we have people from all over the globe. I saw Portugal and Brazil and Mexico and the Netherlands and every place in between. It seems like Romania. So we have quite an international crowd. Let me go ahead and get started. We're gonna screen share here and jump right into this presentation, okay? So the first thing you'll wanna do is make sure that you can actually get to the slide deck. That's the Bitly Cube App Server, a link that you'll wanna have that and that'll get you access to the slide deck, all right? And because that's question number one, how do I get the slides? And from someone else asked, please feel free to remind them on the chat. Now, we're here today talking about Kubernetes is your next application server. And that already is kind of an interesting phrase because if you're just a purely Kubernetes person, you're like, what the hell are you doing calling us an app server? And if you're a hardcore app server person, you're like, what the heck is Kubernetes? So I respect that I put these two words together, these two phrases together and kind of messed with your mind a little bit. But I actually think you're gonna find as we go through the session that it is and feels a lot like our next application server platform at least. So let's get drive right into it. Okay, so the application server definition you see on Wikipedia has these key terms in it. Basically an application server acts as a set of components accessible to the developer through a standard API. Okay, the API is defined in the platform itself and the app server also gives you things like clustering and failover and load balancing. And the key point is so developers can focus on their business logic. So the key words here are APIs, clustering and developers focusing on business logic. And I think if you focus on those three things you'll see why we can actually say maybe Kubernetes is your next application server. So let's actually take you a little bit back in time. So I always like a little history lesson here or there and maybe I have too many in this particular presentation but let's take you back to 1999 because in 1999 one of my favorite movies was born. And actually if you look at the link there at the bottom, the highest grossing movie at that time was actually Star Wars Phantom Menace but because Jar Jar Binks is in that it's by far and way I can't actually claim to that but it was totally awesome. If you actually saw this movie in real time meaning you went to it on opening day or the day after you would remember this opening scene with Trinity where they actually spun her around the room and she kicked the cop backwards. It was absolutely amazing, okay? You might also remember these songs from 1999. I know you guys are big pop music fans but certainly everybody loved No Scrubs from TLC I hope for sure. But you may remember that from 1999. And of course the US wins the World Cup in 1999. Hopefully you all remember that too because I know all you folks from Mexico and Brazil and all those folks from Portugal and Spain and everywhere on Europe, you guys remember we won the World Cup in 1999. And I want you to think about that for a second because it was an amazing win for the US and you might have forgotten that it was in fact US women who won the World Cup. That's the key point because I know many of you were sitting there for the moment going he's telling me a story that's not true but we did win the World Cup. You forgot about the ladies, all right? Gotta remember that. So let's kind of also talk about 1999 from a Java developer standpoint. The Java developer had an interesting 1999. As a matter of fact, you can kind of see that there was this tug of war that we were talking about back then. And this is actually something from Info World from 1999 I picked up when I went back and looked at that timeframe. You'll see things like, you know, Java has your past C++ in terms of a popular programming language. You'll see things like the IDE, right? So IDEs were reviewed back then. If you might even remember things like Semantic Cafe or J Builder or Visual Cafe in this case. So you can see right here that the Visual Cafe cost $25,000 for 10 developers. We used to spend thousands of dollars per developer to get an IDE so we could actually write our code. It was kind of amazing. We spent a lot of money on those things back then. And you might remember VA WebLogic. It was the app server of choice, the product of the year from Info World 1999. You can kind of see this. I pulled this directly from the article. But what did it have? It had amazing clustering capabilities. That was what we were so excited about. In other words, the win with the app server from the very get go wasn't just the APIs and how we built our applications to run within those app servers. It was the fact that it could run our applications at scale. In other words, the app server had this feature called clustering that allowed it to basically run in a HA style architecture. It's a high availability and load balancing. It had failover and had the ability to deploy at great scale. That was a huge thing for us, running our applications successfully. And back in 1999, this is what it cost to build Hello World and actually deploy a Java based web application. In other words, you had to buy a couple sun spark boxes. You had to get a database of course back then and that is our big ticket item. It still is our big ticket item to this day if you're using Oracle as your database. But WebLogic cost $60,000 for a simple, single server in many cases if you price it out. And then of course that visual cafe I talked about earlier. Well, it was not only 25,000 for the licenses, it was 25,000 for support. So it was actually $50,000 to get started. So half a million dollars approximately just to build a simple web application. And you can now be thinking in 2018 how the world has changed. We no longer spend this kind of money. We can launch a VM someplace and basically be up and running for $5 a month kind of thing. So let's talk about APIs. Because I mentioned the APIs, clustering and making this ready for developers is the key critical criteria for app servers and why they're so successful those years. Certainly I've been a long time app server person. I started with a Jboss team before we were acquired by Red Hat and I've used all the app servers pretty much that came out through 1997 up to like now at this point. So I'm very familiar with that concept and I know you are too and that's why you're here today. But think about the stack that we always focused on. Maybe it was a little bit earlier in time. You know, we really focused on Strut, Spring, Hibernate. You remember that SSH, Strut, Spring, Hibernate. And now we're more focused on things like, okay, maybe a, I don't wanna call it a jQuery front-end anymore, we know we're all using Angular or View or React front-end. And not too many people are using IceFaces as much as they used to, but there's still people in all these categories. In other words, we still have some form of front-end. We have some form of middle tier user interface layer like a Spring and we see some people use Jax or S as an API layer. And then we have some form of business logic layer where that be EJB or Spring beans or whatever it might be and a data access layer as well. That's all part of the story and part of our stack. And we had all these standard APIs that came out of the Java E ecosystem as an example. We had all these capabilities that specifically came from our J2E or Java E and now Jakarta E APIs. So things like JSTL that we've certainly seen lots of projects that use JSTL over the years and JSP and Servlet for those basic web applications, JDBC to connect to the database. We had our EJBs for business logic. We had messaging APIs. We had transaction APIs. And we still use many of these things today. We use JPA all over the place. We use ELL all over the place and we use Jax or WS and Jax or S still to the state. So we've taken full advantage of these standard APIs and they gave us the base platform to then innovate on top of that. And that was really the amazing thing that happened within the Java ecosystem was the ability to innovate on top. And so Java E continues on, right? It's no longer part of the Sun world or Oracle world as it once was. Now it's part of the Eclipse Foundation and Jakarta E is its new name and here's this new logo. I encourage you to check it out. Google for more information there but it continues marching on and it's not going anywhere. Now we also have the micro profile as another aspect of that. So micro profile also from the Eclipse Foundation basically is focused on giving us new next gen microservices APIs to help us deal with distributed computing, right? So the original Java E specification kind of focused on everything living in your jar, your bore, your ear, right? Kind of what we refer to that as often as a monolithic application. And now we now want to distribute applications, take those code bases, split them up in small pieces and sprinkle them across the network and call that a microservice. So the micro profile effort was to standardize on those APIs with things like health checks as an example. And you'll see an example of why that matters in a demonstration app for you in a little while. You also will worry about things like how to deal with tracing, how to deal with circuit breaking. All of those aspects are now more important in a distributed microservices fabric, right? We have multiples of these things running around an environment. Okay, we also seen a lot of innovation in the last several years, right? We have all these fat jar architectures. Now our Uber jar architectures, right? Drop wizard really came up with it originally. Vertex right in the same time window there came up with the idea. And now we have Spring Boot, which is very, very popular for building a fat jar architecture. You also have things like Thorntail, a micro profile implementation and popular in that space for micro profile capabilities. And Micronaut, the new kid on the block that you may have heard of just recently that basically also gives you another fat jar style architecture. So this concept is continuing to blossom and grow and I think it will continue to innovate in the space. All right? Now here's the thing that's very critical to me. Not only do you have your base level APIs that come from Java EE, we have always innovated on top of those base APIs. We've always added additional capabilities that moved the whole industry forward. So if you remember Vertex, or sorry, if you remember Spring and Hibernate is two great examples, right? So Hibernate basically showed us a new way to do object relational mapping. Again, if you go back to 1999 or 2001, object relational mapping costs tens of thousands of dollars per server. And when Hibernate came along, we didn't spend tens of thousands of dollars anymore. We just used Hibernate. And of course, Spring showed us a new way to do dependency injection. That of course has now been standardized in CDI, you know, context and dependency injection part of Java EE. But these concepts have moved us all forward, whether it be Apache, Camo, which showed us how to do integration or Vertex that showed us how to do reactive programming or who showed us how to do big data. We've leveraged these things on top of JVMs. We put them in all our application stacks and they're critical to our world going forward. So we can definitely celebrate the goodness, which is all things Java and different Java APIs we love taking advantage of. So let's talk about clusters momentarily, but let me show you a demonstration first, all right? Let's actually pause here for a quick demonstration of something kind of fun, because I wanna show you a few fun things. Let's see, well, how we're gonna show this. I'm gonna show you this concept right here. I have an application and this is actually an application running on my Amazon instance right now. And one thing that you will notice, I actually have three open shifts running, three Kubernetes clusters running, one that is local on my local machine, that's this one over here, this one running at Amazon and this one running at Azure. I'm gonna have different things deployed. I'm gonna show you some different capabilities here. But I have this one called Pop Movie Store, okay? And if you look at the details of the Pop Movie Store, it has this liveness probe and readiness probe. So that's critical. This is unique to Kubernetes. Basically, Kubernetes is saying before I start your component up and agree that it is healthy and happy, I wanna ensure that you pass this test, a liveness probe and readiness probe. And that's part of the clustering architecture of Kubernetes. So this is where we start talking about clusters a little bit, all right? And then if you look at the actual code base, I think I have it running over here still, yes. So here's, if you look at the actual code base, you will see that it has this health check. So literally the health Z is a URL that you exposed through the readiness probe right here. So health Z here and into the code here. And basically it says, make sure your cluster, in this case, the infinite span cluster, which holds the state of our application is healthy and happy and whole. If it's healthy, return it okay. So this is important to understand. You can build a stateful application and that's what we have here. That's living in an ephemeral Kubernetes world and you can do rolling updates against a stateful application. So let's make that point. Let's see if we can get this working. I have this application working over here, all right? And I have it running over here. Let's see right here, okay? And what I wanna do is I wanna give you the URL to this. All right, I wanna give you the URL list is Bitly Pop Movie 2, okay? So you guys should have that. I think I can give it to you in the chat there as well. I want you to join my little application. So you're gonna be running against my application here on this application. So you're gonna have this pop and restore up also, all right? And now I just want you to add things to your shopping cart. So I'm gonna add Bohemian Rhapsody because that was an awesome movie. I just saw it last weekend. Haven't seen Venom yet and we'll add the Smallfoot, okay? And that one, and this is my Safari. I'm gonna add those three things over here. And I'm gonna add a couple items over here in my Firefox just to show you that I have two different users running and I have Stateful in-memory shopping cart now, right? So these elements are part of the application code. And then I have this deployed again back here in, back here in my OpenShift instance, my Kubernetes cluster is running right here and here's the pop movie stirrer we're talking to. And you kinda see there's two pods running right now. And if you look closely at the bottom of your screen, you'll see the name of the pod, the server that it's attached to right down there. It's very tiny, but you can kinda see that between my two browsers, I actually have the two different servers connected, okay? So there's actually two different servers, those pods represent computers that my JVM is running inside and the JVM looks at that as the whole computer itself, right, inside those two pods. Now let's actually go make a change to that code. So you guys should have some things in your shopping cart now and let's go look at, I'll just make a simple change. I'm just gonna update the user interface here to make it simple and we're gonna call this the, we're gonna call this the Mr. Yanagakart of that. This is here helping me today, I'm gonna save that, save that change, go back over here now and I'm going to find the right window and I'm going to run a script that does the deploy and it's gonna deploy my canary build and if all is connected well, looks like it's going, going, going. So this script simply does what's called the fabricate main plugin. It sets it up, establishes itself against that remote host, remote cluster, which is this guy over here, okay. And you notice you see it now says in my user interface it's doing a build and you can see the build occurring right now, build number three created a few seconds ago. So that script I was running on my terminal from this Mac here running in Raleigh, North Carolina, it's reaching out across the internet to that OBShift cluster, that Kubernetes cluster running on Amazon and there it's actually deploying my pod right now. So you can see it doing, it's rolling up data against that pod but we have it set to use zero pods by default. So, you know, again, my, my application is still sitting over here if I hit refresh my browser, right. I still got my old shopping cart data but watch what happens when we start rolling these guys out. So I'm going to roll out the canary deployment and I'm going to come over here and just check on my cart, okay. Just look, my shopping cart's good. I can keep added things to it if I want to as those, I'm going to just keep using the application because we're actually are not impacting the application that's live right now. We're interacting with, we're interacting with these pods that are up right here. Okay, so these are the two app servers, essentially my little spring boot application in this case actually, because it's a spring application using the Infinispan technology that basically gives me a shared shopping cart using the session API across both instances and that's what we're doing now but look at these new guys coming online and you can see one is now ready and two are now ready. So I'm going to go ahead and drop let me go ahead and drop the old ones and I'm going to come over here and keep hitting refresh to see how it looks. Okay, all right, we're still good there. So the application is still up. Let me go and keep killing the old ones. All right, we're just rolling them down and I can come back over here and hit refresh and let's see and this says Yanaga cart and this says, you know what, come on Firefox, get reconnected. Sometimes I notice Firefox is a little bit slower to reconnect than my Safari. My Safari is reconnected, it's got Yanaga cart, Firefox is trying to reconnect but hopefully you see that you have Yanaga cart and all your shopping carts right now on your phone, on your desktop, that kind of thing. So when you get reconnected to that new server you basically see that we're on the new one. So there we are, so both mine are now Yanaga cart and then we can also roll it back. So here's the cool thing about this. We've made a change to the application logic. We actually turned over the entire computer out from under that application. We updated the whole thing. That's what that pod represents, right? It's a Linux container, that's what we think of them. We updated it, rolled it forward and then now we're on this new version of software and the cool thing is if we decided to actually roll back we could roll it all right back and the users and memory state is preserved. So I just wanna show you that concept. So you should be thinking in terms of clusters and one of the primary reasons we love clusters from our old app server days is because it did give us some failover, it gave us some HA, gave us some load balancing, it gave us a stateful behavior that you used to in an old school app server. Looks like a ton of you have joined my presentation now, that's fantastic. So Bitly Cube app server, you got connected to the deck. So let's keep going. You'll see there's a number of hidden slides because we're moving pretty fast today and we wanna keep going and make sure we get to all the cool stuff that we have here. So the cluster, if you're familiar with it from an old school day, the concept of cluster is to make multiple computers, multiple servers to look like one, right? So you might have computer one, computer two, computer three through six and we had the concept of being able to start and stop and restart across these groups of servers, right? We could add a node to this cluster, take a node out of the cluster, we had this concept of farm deployment where in the case of JBoss in particular, that was one of the things we used to show you back in 2005, 2006, right? Plus the concept was I could deploy my EAR file to one node in the JBoss cluster and it would actually then deploy to all the nodes in the JBoss cluster. It would roll it out across all the different JBoss application servers as an example and of course, JBoss is using J groups for that clustering architecture to maintain that connectivity between all those nodes. You could update configuration across the cluster, right? If I had to change my database configuration, if I had to change my drivers, I had to change my load balancing, my failover, I had service discovery, I had logging. So all these things were what we've received in our clustered app servers of web object, web sphere and others and this is why we love them because it kept our application running healthy and happy and a little bit like what I just showed you, right? With my little application. Now, here's the thing that should be considered, right? We actually had our ears and wars primarily running across those app servers, right? We put our jars in our wars, our wars in our ears. That was the deployment artifact that worked across an app server cluster and the deployment artifact that works against a Kubernetes cluster is now this concept of the Linux container, the Docker Linux container. Now, we also had this concept of the main controller. Hopefully you remember that. We had that in web logic, we have that in JBoss, right? So the concept of the main controller basically is the entity that's controlling all those individual nodes and you'll see in a Kubernetes cluster we have the same kind of concept. We have our individual nodes, our individual computers. They're all running Linux out there, these nice big servers if you will but they're not running wars, ears or jars. They're running Linux containers and you can pack anything you want in those Linux containers. If I want a Tomcat, if I want a Spring Boot, if I want a Wildfly, if I want a Python, if I want to go, if I want to Node.js, if I want to my SQL or Postgres, so you can have stateful workloads or stateless workloads. Anything that lives happily in a Linux container can live across this Kubernetes cluster. So again, the same things apply, right? I can start and stop and restart. I can add and remove nodes. I can have farm deployment, meaning I can tell Kubernetes, please deploy my component and it'll roll it out there, moving it to the server that is most available and fits its needs. So that little deployment you saw me do earlier with the script, that's all it's doing. It's basically using a fabricate Maven plugin and it's basically saying take this war file and redeploy it to the Linux container that's out there and basically create the new Docker image, create the new image in the Linux container and the Kubernetes is scheduling it across the cluster. So all those same things you're used to from an app server clustering standpoint, pretty much you're also available here, but you can use anything you want now. So let's talk a little bit about microservices before we run out of time today because microservices is all the hoop cloud, right? We're all excited about them. And this side you've probably seen from me before. I like putting things in context and giving it a little history lesson, but we've been thinking about this problem of microservices quite some time. And the cloud was born back in 2006. That was a huge thing that changed the way we think about application architecture. You can also see Drop Wizard and Vertex back in 2011, gave us the Fat Jar concept. Netflix, of course, went open source back in 2012. That gave us Histrix, Eureka, and Ribbon, right? Changing the way we think about how applications communicate, at least with JVM-based applications. And of course, the perfect storm was when Spring Boot and Docker were born back in 2013 and Kubernetes was born back in 2014. And of course, we defined microservices as a concept officially with that famous article from Mr. Fowler and Mr. Lewis over at ThoughtWorks. Also in 2015, you might have saw this presentation from us and there's a link in the bottom of this chart here where we showed you how amazing Kubernetes was by launching 1,000 plus containers live on stage, 1,000 app servers live on stage where the audience had a chance to actually play along and claim one of those app servers in that 1,000. And we did all that in two and a half minutes. So that was an amazing demonstration. I encourage you to go back and check it. It also has a really cool IoT thing and mobile thing that we did there too. So if you're interested in IoT, it's got a really awesome IoT demo there. But as of 2017 though, the world has now realized we all love Kubernetes. The people who previously fought against it like your Pivotals and Mesosphere and Dockers and even your Amazons now have agreed, Kubernetes is the de facto standard going forward, okay? And the Cloud Native Landscape here, the Cloud Native Computing Foundation where Kubernetes comes from has exploded, right? In terms of everybody, all these different vendors, all these different startups and open source projects contributing to that overall architecture. So if you remember back when I said in 1999, you paid half a million dollars for getting Hello World, a Java Hello World up and running on the web. Now all of this is open source and that's what's so amazing. All this amazing infrastructure that makes you cloud ready in your data center, on your laptop, in the public cloud, now give you these things from an open source standpoint, okay? So let's actually show you one little other thing because I wanna get to the next demo before we run out of time and that is remember, it's all about Dev and Ops working together. We have to tear down this wall of confusion between Dev and Ops. I know most of my folks here today are on the Dev side but I imagine some of you are also on the Ops side and of course the Devs think they're Lego man but I do think of the Ops as a wizard, all right? You guys are definitely a wizard. But what we can't do is keep throwing it over the wall and hitting the other guy in the head. As a matter of fact, our job is to tear down this wall and we have to deliver better software together. That is our mission, that is our goal. If we're not delivering software ever faster, we're not actually contributing to the greater good of our organization. I love saying if your code doesn't make it a production or doesn't make it a production rapidly, you've offered no value to your organization. I don't care how many lines of code you created and how elegant your algorithms are and how many times you check it into the source code repository until it lands in production, there is no value, all right? So that's what we should be thinking of. So let's actually show you a couple of things because I wanna show you this one next demonstration. And actually the demonstration is gonna be based on this technology called the Cupid Dispatch Router. And I actually had a huge problem before we got started today. As I mentioned, I have my local cloud running here, okay? So this is my local cloud running an OpenShift instance running inside a virtual machine on my local machine. But I also have my Amazon instance and actually just switch projects over here, okay? I have my Amazon instance running here and I have my Azure instance running here. And so here's my Azure dashboard, my EC2 dashboard and you look at my lonely Google dashboard. So the lesson learned here is Google went belly up on me today, it just totally died or at least last night. We could not bring it back to life, it still needs some resuscitation. So this demo used to be a four cloud demo because the point of it is your application runs across all clouds. If you build it to Kubernetes, you build it to OpenShift and that's why this demonstration, this particular application is so cool, but Google died on me, but that's okay. Our application is still running across the three other clouds. So let's kind of make that point. I wanna show you another URL. I need your help right now to join me. I want you to go to this URL, all right? It's bit.lyhybridopen2. Go to bit.lyhybridopen2. You're gonna get a user interface that looks like this one, okay? Where you can type in messages. I wanna type in a message one, okay? And you notice it says Merhaba one. So for my friends from Turkey, I was in Turkey not too long ago, so I got a Merhaba in here. And it's responding from Amazon, okay? So I type that message in, let's say I put in my name and I type that in and you can see it responds from Amazon. So you're getting your responses from Amazon because by default our specialized router is connecting you to your local cluster and that in this case is Amazon. So if I look at my user interface over here, you can see that I have the Burr server running here. I have Amazon and I have Azure. And notice the routing logic here. We're running on Amazon right now, but it routes back through Burr and out to Azure. So let's actually make that point. You can also watch our message flow here. Yeah, there's our messages flowing, okay? And then so let's do this real quick. I'm gonna go back over here to my Amazon instance and I'm gonna turn off the local worker. So this is the consumer of your message. So you're producing messages, right? It's being consumed, it's being processed by this worker here. I'm turning it off now and you're gonna see, okay, let's put in Burr again, right here. And there you go. You're now getting a loa from Burr, okay? So you now have failed over from the Amazon cloud to the Burr cloud and actually it's not even failed over. The coolest part here is that the transaction processor is now on Burr, not on Amazon and you're interacting with Burr. So think about that for a second. You're coming from somewhere in Turkey or Mexico or Brazil or Portugal, right? Or the Netherlands or over in Asia and India and your transactions are now coming to my laptop and I'm broadcasting from this laptop to you. That can get really painful because this might get really slow with all this recording software we're running right now. But let's have a little more fun with it. I'm gonna go into my local server now and watch what happens. I'm gonna turn off my local server. Okay, this is my local one. Same application deployed across all these clouds and you're gonna see, okay, what happens next. Let's go over here. Let's go over here. Go here and put my name in again. And now you're on Azure, okay? So we basically have routed your transactions around the internet a couple of times it seems like now. So basically you were on Amazon, that's where your interface is and then you basically routed to my cloud here on my laptop and now it's being routed out to Azure because that's where the work can be done. So this is an important concept I want you to keep in mind. Not only did I deploy that same application, the same Java application in this case. It's a Vertex-based application that uses a special technology called AMQP that is routing messages across the entire internet. But we are now failing over from cloud to cloud to cloud. And what's really cool is if I have a situation where maybe I have too much load, let's actually do that real quick. I wanna crank up the load generator. Okay, I'm gonna crank up some load. So not only are you guys pushing load into my system but I'm actually gonna really hammer the system now and you can kinda watch the performance characteristics of that system once it comes online. Okay, we will start pushing load into the system and let me come over here and actually I wanna bring Burr back up too. So we just have, we actually have enough processors to run these transactions. Let's see here, scale that Burr node back up also. And so there we go and look over here. Yep, you can see messages starting to flow now between Amazon and Burr. If I look over here and see our chart, you can kinda see that, so Burr is taking about 95 transactions per second. Okay, Amazon, did I bring my Amazon back up? Sometimes I do the wrong one. Oh, let's bring Amazon back online too, there we go. Let's actually do that. So basically what was happening is all the Amazon transactions were coming to Burr and in some cases going out to Azure, let's bring Amazon back online so it's actually handling a lot of load there. We can actually see in this case, Amazon transactions are literally coming over to Burr for processing in some cases. And of course you guys are processing, pushing transactions to the system. None are going to Azure right now, but that's only true because I need to push this system a little bit harder. So I'm gonna actually create a lot of work up on the Burr node, the Burr cluster, and that'll probably tip it over the edge so that Azure also takes some of these messages. So you can kinda see Burr pushing here as that one comes online. And let me come over here and check my user interface again. So what we're gonna do, and let's see what it looks like. All right, so yep, we're still on Amazon there because this user interface is connected to Amazon. Okay, and let's see what it looks like here. There we go, all right, because you can see Burr doing some of the load here. You can see Amazon handling some load, Azure handling a little bit of load too. So this is a very cool technology. We don't have time to explore it all the day, but just be aware of it. It's called the Apache Cupid Dispatch Brouter. It allows us to do this amazing thing. The actual demo you saw me running is actually at this URL, GitHub Burr Sutter Demo 2 AMQ. Do check that out. There's also the ability to run Kafka at great scale with StremZ. You can also play with this technology called Debezium which allows you to actually take database data in real time and real time ETL out of databases through Kafka. So you can complement these two things with each other. There's also SSO capability that you can run on a Kubernetes architecture. You can even run your IDE in Kubernetes with Eclipse J. So keep that in mind. There's all these amazing things you can do with a Kubernetes based backbone. You couldn't do it a regular old app server before with your app server capabilities, even a microservices architecture like that Spring Boot application I showed you is still available today. Well, that is all we have time for. I'm hoping Ed's in the hand of all your questions because we were basically moving too fast to come back and talk about questions. But I thank you for your time today. We're gonna let you get access to these links, right? That gives you access to the slide deck which gives you access to the rest of the world. And don't forget about our free eBooks and whatnot. I mentioned these many times if you're interested in microservices, reactive microservices, SDO technology, migrating your microservices to microservice databases. All those things are available. That's Edson's book that's available there. That's all in slide deck and available to you. I thank you for your time. Always check us out on Twitter and check us out on email. You have the email from me based on getting the invite to the session. You can always respond to me on email and I'll try to get to it as quickly as I can. Thank you so much.