 Well, hello and welcome to another Dev Nation Live. I'm sitting over here in a hotel in Napa Valley. We're gonna be having a presentation today at SwampUp, the JFrog conference, but I'm gonna give you this presentation right now. We had a lot of people registered for this event. We have hundreds of people on the line. And remember, in the chat tab, please make sure to help each other out. There's the link that I provided for today's slides. There's also a link to the previous recordings. I'll get this one updated as soon as possible. But today I'm the host and the presenter. So you guys are gonna have to help me out on the chat tab with each other because I want me to see the chat tab once we go into sharing mode. Do feel free to put all your questions in the Q&A tab, questions and answers tab, and I'll get to those at the end after we stop screen sharing. But let's go ahead and get started right here with the screen share. And we'll go into slideware mode, okay? And I'll give you this presentation. You can see a lot of over 21 people have already joined my slide deck. And this is a live document on Google Docs. Once you guys have it, it is free for you to keep. And you want this presentation because there's a link at the bottom for it, dnl underscore server full, but it gives you access to a lot of other links. So we're gonna move through this very quickly. And for those of you who are not hearing or seeing right now, remember, it's fresh to the browser, but you probably can't hear or see. So if you guys would help each other in the chat. All right, here we go. Like I said, lots of links. We're gonna talk a little bit about microservices today, but not really so much because microservices is like the two to three year old thing and we're gonna talk more about serverless today, a little bit at least and kind of bridge that gap for you. But you can see there's a ton of free ebooks you should have available to you for intro to microservices like their Java microservices book, the reactive microservices book. We have demonstrations that you can walk through. There's a huge slide deck as well as video training, tons of advanced materials as well. We have this great Istio tutorial and a deep dive. Also, if you look at these two links near the bottom, the learn.omship.com, if you don't want to install anything on your laptop, if you just want to try to get your hands on Istio or get your hands on Function as a Service Serverless, you can just go to those URLs and get started. But don't do that right now because I'm gonna be talking to you for a little bit longer. Okay, but there's the link to our slide deck. And remember, lots of links here. There's also this great book, another free ebook I'd highly recommend because one of the biggest challenges with microservices is how to deal with your database. And we've had this content on Denation Live before. We can do more of these sessions with Edson Yanaga. Just let me know via email or Twitter or something and we'll get more of that content for you. Also, we did publish just recently our Istio book, right? So they're free, a Riley ebook on Istio. Do check that out, Christian Post and I put that together and it's based on the same content we've already mentioned, okay? Now, this talk that we have right now came up because we did this big demo last week at Red Hat Summit last Thursday, just a few days ago. And this is where all of these ideas came together. We had a massive application built with microservices and functions. Also, we had a trained AI algorithm as part of that architecture. And what we had people do was upload images and we have a kind of a scavenger hunt, wears, Waldo kind of thing. And when you uploaded images into our system we gave you scores and points based on the AI model and we had a real-time dashboard you can kind of see there in that screenshot. I encourage you to go watch that YouTube video at some point. It's about 25 minutes, I believe, for that overall demo but it walks you through a lot of things that are super cool in my opinion. But that's where this talk came from was we had to create that demo and then I've now created kind of a presentation around that. Now, great quote here from this fellow here, the blonde guy with Thor. Our ancestors call it magic but you can call it computer science. I added the computer there so the quote wasn't directly from Thor. But I come from a land where they're one and the same. So just keep that in mind. We're gonna do some really cool stuff here. And that's the thing I love about technology in general and the reason I've been passionate about it for the last 30 years is it's always changing. We're always learning and finding new superpowers that you're gonna see today. In the case of where we've been, we had our monolithic application, it was fairly well understood. We knew how to build a J2E or Java application or a spring MVC application or C-Sharp.net application or a lamp application. It didn't really matter what the technology was. We knew how to build a monolith pretty well. We'd been doing that for good 20 solid years or so at least in the web application world and even before that in the distributed world or in the mainframe world. But what's happened is we've kind of broken up the application into modules or components over time making it easier to maintain, hopefully. But we now have seen this model monolith fading into the background with microservices. So the microservices start becoming the thing and the monolith kind of fades into an in existence at this point. And we have a challenge before us. We have to distribute these microservices into an overall network of services into a distributed mesh. And that's where things get weird and odd and challenging. And there's lots of solutions to that. And I highly encourage you to go back and watch our recording on Istio where we kind of dive into this a little bit more. But this concept is what makes microservices challenging. Also, I mentioned that there's the free ebook. Microservices also have their own database. You no longer have a monolithic database, monolithic schema. You now have multiple databases, multiple schemas to represent those microservices. You can have multiple points of entry. This also makes things a little bit challenging. You have multiple ways to get to those backend APIs. You can kind of see there we have some direct access to different microservices in the architecture. And as I mentioned, Istio helps us solve some of these challenges, right? So you have Kubernetes and OpenShift as the backplane to run all those different microservices because you don't necessarily want to keep up 20 or 30 or 100 of these things all the time. You want Kubernetes to keep them up, make sure they're healthy, move them to healthy nodes on the server network and generally just keep your infrastructure up. What Istio does is add some of those capabilities into the component services themselves. So pre Istio, right? In the old days of Netflix, OSS and Spring Boot annotations, Spring Cloud annotations, you added service discovery and load balancing and resiliency and metrics and tracing. You added that into the JVM itself. And of course, the JVM gained weight accordingly because you had now this additional complexity. But it did help you protect yourself from breakage in the network, if you will, from problems inside that network mesh of services. After Istio is applied, right? We have the concept of the sidecar container and the sidecar container takes on those capabilities and we no longer have to worry about them as much. They've externalized the discovery, the load balancing, the circuit breaking, pushing them off into the sidecar and letting Istio manage those. So just keep that in mind. That's really why Istio is so interesting and so exciting to most people right now. And we did record a previous session on that topic. Today, we're mostly trying to compare or contrast the service mesh and microservice world with the serverless world. Okay, so I just kind of just a recap here. All of this, of course, was to make sure that we didn't have failure in our system. So if we did have a failure, like this is the one thing with the red X here, one of those microservices, we didn't want to cascading fail. So basically everybody dependent on that component didn't also fail and everyone dependent on them didn't also fail. So the concept of a circuit breaker, that concept of resiliency, that concept of load balancing, you want that in your infrastructure itself and you get the basis of that with Kubernetes and OpenShift but then with Istio, you had another great layer on top. So that's what this chart was about. And again, we spoke about Istio already just a couple of months ago, but you can kind of see where I have, where Kubernetes really added a lot of capabilities to help your microservices. OpenShift, of course, augments that in addition to that and Istio augments it even further, right? Where Istio helps you with tracing, resiliency, authentication, discovery, things like that. But at this point microservices architecture should be pretty well understood, okay? So change happens. There's Mr. Spock there. Change is the essential process of all existence. I love that quote. So new things are happening. In the case of our mesh of services, we can now replace some of them with functions and a microservice is different than a function. And when I say function here, I mean functional programming. I mean function as a service or a serverless architecture. You can still use them in a composite whole like you see here in this chart, but it is a different programming model and I'll just show you that briefly. And it should be noted we have a deeper dive into function as a service and OpenWisk in particular, all running on Kubernetes and OpenShift in our next DevMation live coming up on June 7th. So just keep that up, keep in mind. Here's my super simple way of defining where you might want versus the other. And if you remember that demo I mentioned from last week where we showed you microservices and functions with the AI train model, we actually have that concept there. So the concept of microservice is really applicable when you want full control of the life cycle of your component. In other words, you, the operations team, development team own the control of that microservice. You know when it starts, you know when it stops. And in the case of Kubernetes, you're letting Kubernetes start and stop it in most cases, but you have control of that. It's a long running process, meaning the process of lives and breathes and just sits there consuming CPU and memory all the time. It's always on kind of thing. And it's really good for like a streaming web socket kind of use case where if you watch your demo from last week, you'll see that we have a real time connection to each mobile browser. We had over a thousand people on their mobile phones talking to us in real time through their mobile phone. And then we had a dashboard where you see all the data streaming out of the backend based on the transactions as they're being performed. Again, another web socket type use case. That requires more of a long live process. It requires kind of a always on infrastructure, great for microservices. And that's really good for my Vertex in particular. Vertex is a great solution for that sort of reactive style, always on architecture. And it is a known programming model. And I think that's very important. And maybe the most important thing about your decision to go with microservices versus functions. A microservice looks just like the programming model of the monolith. You have Jax or S for a rest endpoint. If you're a Java E person, you have Spring MVC. You have, you know, if you come from that world, you basically are building an application just like you always did. The difference is in size and scope. So microservice is, has a smaller scope than your monolithic application. And you might put it in a Linux container and running on Kubernetes is an example. But the programming model is identical. You don't have to go through any real learning curve other than dealing with the distributed nature of microservices. And that's where you add things like service discovery, resiliency, load balancing, circuit breaking, and that's where Istio helps. On the other side of the equation though, on the function side, you don't have control, right? The cloud has control. It determines when it starts and stops. You don't have that control anymore. It's for a very short live process. These things typically only last a few seconds, milliseconds to seconds. And sometimes they last maybe a couple of minutes, but the infrastructure probably won't let it live that long. The nice thing about having your own function as a service engine is you can tune that. You know, you on the operation side can tune that to decide how long those processes live. Maybe you wanna make them five minutes or even longer. But by default, the cloud, if you will, the FAS engine is responsible for that. It is a new programming model. So a very different programming model what you've seen before. I'll show you some quick examples of that. But that really may be the big scotcha. A new way of thinking about application architecture, a new programming model that's different than what we had in the last 15 years. It is an event-driven programming model too. Everything is async in a serverless function world. So you gotta get your head around that and that could be challenging. In a microservices world, it looks just like regular request response for most people, right? It's the HTTP get, HTTP post, standard stuff, all rest, you know, typically most people are using rest or JSON payloads. Pretty normal stuff in the microservices world. Now I know there's purists out there would say, hey, you can do event-driven microservice and you can. And you could also apply the old programming model to functions. Yes, you can. You can mix and match these things to death. I'm just kind of giving you what the default is as of this moment. And the one big scotcha in the serverless world is not as mature. And you might even see that as I demo a little bit of it today. But just keep that in mind. There's not as much IDE integration. There's not as many debuggers available to you. There's not as many tracers and monitoring solutions available to you. The CICD aspects are a little bit unknown to this point. But these things will be documented, will be figured out, documented, described. Examples will be coming out. And over the next year or two, you're gonna see it really mature into a fully fleshed out programming model and be as mature as the microservices paradigm. And then I'm gonna find, I'm sure we're gonna find more people mixing and matching microservices and functions going forward. Okay. Now, how do you determine should you go serverless or server full? All right, I'm calling microservices server full. How about that? I'm just having fun with playing on words there. But the real nut of it is, when you're going into a serverless architecture or in functionless service architecture, you first are thinking with a different question. You're starting with, is there a service I can use before I build one? Okay. So buy versus build. In a microservices architecture, you typically build, right? I'm gonna build this rest endpoint, that rest endpoint, put it in this container. It's my Spring Boot app over here. It's my Vertex app over there. My micro profile component over there, put it in a container, run it on something like Kubernetes. That's typically your mindset in a microservices architecture. Very similar to the mindset we had in a monolithic architecture, but it is typically build first. In the case of serverless architecture, it's more buy first. What can I consume that already exists? So that becomes important. So it's serverless because of software as a service where other people are managing those servers on your behalf. It could be other people within your big organization for managing a much infrastructure for you, or it could be you're running all these things on Amazon, on Google, on Oracle, on IBM, on Microsoft Azure, one big public cloud providers. So serverless is defined as a back, you can have back in as a service and we have this concept of function as a service. These are femoral containers that are running our functions. And I think it makes more sense to show it to you. So we'll show it to you in just a second. It's fundamentally all about the services. So you might have an HTTP gateway as a service, basically HTTP in and out. So get, put, post and delete coming through that gateway. You might have a single sign on as a service. You might have some form of file storage as a service. And by the way, storage and single sign on are in that big demo I mentioned last week. You also might have a caching service, a database service. I consider all these services to be critical and you don't really want them, embed them in your application. You would love to consume them from the ecosystem as a whole or maybe from services that have been deployed into your open shipped environment in your private cloud. Depending on what your organization decides to do, there are a lot of ways to handle it. You might have a notification service, a messaging service where you have some form of AMQP flowing in and out or you might have some form of notification, whether it be to a browser or to an actual iPhone or Android phone, it doesn't really matter, maybe even email notification. But all of these are services that have unique APIs that you can interact with. And you can still have microservices in your architecture for those long running processes, always on components that are basically part of the system. Maybe these are relatively large code bases that are doing really advanced or robust business logic. It doesn't really fit in the context of a function if you will, it is a big old thing, great for those microservices from that perspective. But functions become the connective tissue, their event driven input and output that help you connect the dots. And you can have numerous functions that basically sync up the application. And like I said, that connective tissue where things are really happening from an event driven kind of perspective. It can all be part of the same architecture. And of course, you get the synergistic relationship that gives you a real cool business of business transaction, mobile application or an API feeding a desktop. Whatever you wanna expose on the front end is just up for you to choose. Again, that demo I mentioned from the last week handles this in a smaller version of this, if you will, but it does show you many of these capabilities as an example. We show you the data, we show the storage, the SSO, we show you how to get input and output from a microservice as well as functions running the AI component as an example and a notification solution. Now there are numerous players and the function has a service space. Okay, there's many more than this. These are just the ones I've been interested in and looked at recently. The, you can see Project RIF coming out of the Pivotal team, Spring team, FN project coming from Oracle team, OpenFaz also coming out of the VMware team, VMware. And it seems to have like three or four of these things, you know, over there where they're at. So some players have more than one option in the space. And, but the one we're betting on here at Red Hat is OpenWisk. So just keep that in mind. OpenWisk is already in production usage at IBM's public cloud and in Adobe's public cloud, both of which are providing functions and service capabilities to their developers and their users. And we are in the process of bringing OpenWisk and making it a first class citizen as part of Kubernetes and OpenShift. And that's what we've done and that's what we showed in a big way last week. And as I mentioned, there's that learn.OpenShift.com slash serverless where you can try it yourself. Okay, and even the little Hello World demo I'll do in a minute, you can try it yourself as an example. So highly encourage you to do so and get us that feedback. We want your feedback. It's like any other open source effort you've seen from Red Hat. We wanna know if you like it, if you hate it, what you wanna tell us about it, help us improve it. Okay, some aspects of the platform you should be aware of and I recognize them going fast, but you know, we only have a few minutes together today and there's lots of other links in the presentation for you to drill down. But one thing about this platform concept, when we were traditionally on premise, we were responsible for everything, the full stack of our application, right? The server, the storage, the networking, the actual hardware environment itself, operating system, virtualization, the runtime of our application where they'd be the JVM, the V8 runtime for Node.js, the CPython runtime for Python. You know, our language runtime was part of it. We of course had all the data and we had all our application and business logic. You can see to the far right here the function as a service means you just focus on the business logic and you throw your business logic at the system and the system figures out the rest. So that's really why people are excited about this technology. It allows a developer to be further abstracted away from the infrastructure. In the case of a microservice running inside a container and running inside a container platform, you do feel some of that infrastructure. When you write that Docker file, right, you're kind in the infrastructure world. When you actually start thinking about Istio, you're kind in the infrastructure world and the function world, you can kind of ignore all that. It just kind of disappears. So that's why some people are very excited about functions as a service. OpenWISC, as I mentioned, has an Apache project and so it does support multiple function languages like JavaScript, Swift, Java, Python and I'll show you JavaScript, Python and Java just as a quick example. You can also use any kind of Docker container as a function as well, which is pretty powerful which means anything that can be packed in a container which is almost everything these days can also be run as a function. The trick is understanding your event streams and your triggers so that the event stream fires off the right function at the right time and of course that function can then produce its own events or produce whatever results you want, okay? There's a lot of terms that live in the OpenWISC world. The one key one I would encourage you to think about today is actions, actions are basically functions, okay? It's a code snippet that gets executed based on a certain event happening within the system. So think of that as your function, okay? Action, function. I think it's funny they didn't call it function and they call it action because for me I'm kind of old school that sounds like a struts one kind of thing, right? We also had actions in the old JBoss ESB for anyone who's been around that long, okay? Right, so here's our JavaScript function. Here's how easy it is and I mentioned that the programming model is unique. It is basically a main method with parameters, that's it. You get input JSON and you output JSON. That's kind of the way this works and that's actually very cool. And then you have a command line tool to basically inject your code into the OpenWISC runtime. So there's a WSK command line tool and you say action update, the name of the action you're updating and then the source code or the compiled code or binary code or zip file, whatever code you want into that system. And if it's just a single JavaScript function, it's pretty straightforward. You can also do a zip file with a full JavaScript application or you can have a jar file in the case of a Java application. It all depends on what the proper thing is for that programming language. And then you can invoke it. So one nice thing about the way OpenWISC sets up the functions is you can invoke those functions locally immediately through unit test because it's just a simple input and output. So unit testing and integration testing at the command line level, in your Jenkins CI CD build pipeline, any of that is just perfectly simple because there's no weirdness if you will when it comes to the input and output. You just basically inject your JSON and you get back JSON as an example. But they have a nice command line tool for invoking it within the system itself. And you see WISC command action invoke the name of the action and whatever parameters you wanna send in and dash dash results as wait for the result to come back. All right, and that's an important element also to wait for that result. There's also another concept for getting an asynchronous result. And there's the result of that one. And if you do wanna wait for asynchronous results as well as seed logs, then WSK-I activation and get-L is a hot tip for you that gets you the last activation where you can see the logs, things like that. Okay, there's also Python. Here's what Python looks like. Any kind of idea? You know, and we'll show you this here in a second before we run out of time. And then there's Java. Now, the Java is a little bit more verbose as Java is, right? Because it's not a dynamic language, it's a statically typed language that's pre-compiled. And it also doesn't really have JSON as a native construct, if you will. You have to do a little more work for your JSON, but this is the exact same thing you saw in Python and JavaScript, but in the Java version. And unfortunately, it doesn't quite all fit on my slide here like it previously did, okay? And there's also maybe an archetype that we provide. So keep in mind, if you're interested in what I just showed you here, there's a bit.ly link for FAS tutorial. I mentioned this earlier. And if you don't wanna install it all, like I'm installed it all here today, you can go to learn.objip.com, so I serve this, okay? So let's just show you this stuff. Let's go ahead and give you a quick demo of this. And our goal today is not the deep dive. We have a deep dive for our next session. You guys get a chance to see that later. Let's see here. Okay, WSK. So notice the dash I has to do with the fact that we have a self-signed cert. We're just trying to get around that. There's a way around that, and but otherwise I just have kind of memorized WSK. WSK dash I and like action list. So you can see there's a action list which shows you all the actions that are currently in the system. Let's see, grep message action. I already have one out here. So there it is. And I can invoke it. I think I have my invoker queued up here, okay? So I can invoke that action. You can see it's a JavaScript on OpenWISK on OpenShift. Now, so basically it is already pre-deployed. It's out there. I'm just basically executing it. But let's show you this right here. Let me shift console. And this is all running a mini shift. Basically my local OpenShift environment. Let's bring up the console though. Yep, yep, yep. Let's go into OpenWISK. Here's the backend architecture for OpenWISK itself. It's running in its own namespace. And you can see there's a lot of pods associated with it that represent the architecture. We're not here to really walk through that detail today, but just get a feel for that, that it is there. But watch this trick. I mentioned that functions are ephemeral. They are still running as Linux container. So however, and this is the important part I think, status in is, okay, add that. And now watch what happens, okay? And when I invoke, you will see a container pop to life. And then you'll see a container go away, okay? So as long as I'm banging on that component, you'll see that container there. But at some point it times out and goes away. So that basic concept, so now it's gone, is why we call these things ephemeral, okay? So the function is still running in a Linux container, but then it's kind of disappearing and going away. Now let's try this. Let's actually update to the Python version. I mentioned earlier. Now we have the Python version. So I'm actually still making the same client invocation. And by the way, this all works through HTTP as well. The WISK command line tool is just using HTTP. But now I've basically invoked it via JavaScript or I call the JavaScript function, but I replaced it now with a Python function. So now we have the Python function. And it can even go so far to replace it with the Java function. You can kind of see the Java one's a little bit trickier because they have to add the jar file as well as identify what its main method is. You know, if there's several classes in there and there can be, which is the one that has the main method we wish to invoke that starts everything off. And now if I invoke, you can see that we have the Java component right there. So in this case, from the client's perspective, I can replace the programming logic completely of different functions at different times. You can see I have the Java version right now. If I come back over here and go back to the JavaScript one, okay, now if I come back and invoke again, you'll see we're back on JavaScript now. So I know that concept is kind of wild. That is in very nature of the event-driven architecture and this concept of function as a service and what you're seeing in the service architecture. Again, we're just here to give you a taste of this today, there's a lot more that will come in the next demonstration live. And then of course you can watch that demo, you can also try it online yourself just to give you a taste today. Again, there is an archetype that we've been working on and it'll give you the initial code base there. And actually, let's do this real quick. Let me bring up the code base for the Java piece. I say that's only because I'm a Java person. So here's what the Java code looks like kind of thing. And again, it gets generated for you automatically. I'm just using Visual Studio Code here, Visual Studio Code with the red hat plugin for Java. See, right here, language support for Java, for red hat, almost 5 million people downloaded at this point. So that's awesome. But that's what I'm using and you can kind of see what this thing looks like right now. So pretty basic code base is just input JSON, processing the parameters, output JSON. That's really all it's doing and numerator them all. And notice I have system out the print lines there. As I mentioned, there is this little secret command. Let's go, come on, to get the last activation. Now I'm gonna just copy it out, paste it in. And that's how you see your system out of the print line. We'll see it there. Okay, so you can see the result and other information. So that's a nice handy little tool to remember so you can kind of see what's going on inside the application. And then do I have the JavaScript one here? Let's see JavaScript. Okay, and actually, let's go back to the Java one. I'm kind of curious. Let's put that, look at one more time. There we go. See if we can get that last activation. There we go. Nope, that's still the JavaScript one. So the timing of activation is a little bit slower. You might have to wait a moment to get that information. There's the Java one right there. Okay, all right. And you can even see the system out of the print line stuff that I had there. All right, so we are almost out of time. Let's kind of wrap this up. And I will give you guys a link to the presentation again and we'll answer some questions. What else do we have? Okay, yep, we showed you that. Again, the presentation link is this one right here, bit.lydnl underscore serverful. I'll paste that back in the chat as I flip back over here and stop screen sharing and we'll answer some questions. So stop screen sharing and there will be a recording. Let me add the bit.lydnl link to the chat and let's look at what we have for questions. So the buy first strategy, how does it not lead to vendor lock-in? Well, in the case of vendor lock-in, if that really does worry you, if you use anyone's API, you are bound to that API forever more. However, there is a special thing happening right now that I'm pretty excited about. Let's see if I can find the URL for you real fast. This is a project I'm monitoring personally. I'm very interested in it. It's called Cloud Events I.O. So basically, let me add this to the chat. This URL is something you wanna remember, Cloud Events I.O because they're trying to make it so it's portable, a portable abstraction layer for your event-driven input and output. A good example of Istio. So can you suggest a good example of Istio in a real-life environment? Yeah, so we're not talking about Istio so much today, but if you go back and look at our Istio talk from just a little while ago, you'll see some of those ideas there. But Istio is really awesome in a situation where you do have several microservices and you have the Spring Boot, Spring Cloud annotations all throughout in the love of the place and you really wanna remove all that infrastructure if you will from your business logic and put it back in the infrastructure. If you only have one or two microservices, I could argue you're not really doing microservices, you're doing baby monoliths in that case. But if you do have 20, 50, 200 microservices all running inside your backplane and you really wanna have a cohesive strategy for dealing with the route rules amongst those microservices, there's really awesome routing logic associated with Istio. You also have the concept of built-in tracing, built-in circuit breaking, the ability to do chaos engineering. Basically, I'd encourage you to check out that Istio tutorial that we mentioned and that free Istio ebook that covers all that in a lot of fun, cool ways. Are there other ways to invoke functions than a command line? Totally, so Martin, great question from you. You can use the command line tool but it's just an HTTP put and post that we could show you there. So just keep that in mind. You could use HTTP straight up and open-wisk. That's no problem. And any other event stream that you mind in could be the way to invoke the function, AMQP, files showing up in a file system. What you'll see in our demo from last week, we have files showing up in a S3-compatible API-based Gluster Storage and that storage is running across the entire hybrid cloud. So we have your files you upload running on Amazon, Azure, and our private cloud. It runs on any cloud and we have functions responding to that upload event. So there's lots of ways to fire a function as an example. And we are basically at a time. Getting started, restarting, okay. But let's answer this one last question. Is open-wisk a supported product by Red Hat? It is not a supported product. It is an Apache open-source project. We are in the process of going to the productization process making it ready for a future support subscription but it's not there today. We're just kind of getting out in the community and working hard in the upstream to make sure it's ready to go for Kubernetes users, ready to go for OpenShift users. And we're getting customer feedback on that now. We're just working with our users on that. Okay, there's plenty of other questions but I apologize we won't have time for them. Do hit me up on Twitter. We had a few hundred of you here today so couldn't quite get to everybody. But also hit me up on email. You should all have my email address based on the fact that I've been emailing you about these DevNationLive events. And if you guys have other topics you'd like to see more information about, please let me know and we can either get you the recording from that session or get that person back to talk about this topic again, whether it be the Istio, the databases, the micro profile, the Vertex, reactive system, how to do spring boot on Kubernetes. We have all that content that's already out there, SSO capability, key cloak, already part of the recorded DevNationLives. I thank you so much for your time today. And again, feel free to reach out to me on Twitter, or via email, and we'll certainly get back in touch with you. Thank you.