 Yes, I'm here, Beth Massie with Brian Benz. Brian, tell us a little bit about yourself. So Brian Benz, I'm actually based in Las Vegas, which is where we're recording this. This is your time. So yeah, I just drove in here and I've been working at Microsoft for about five years, mostly on Java on Azure, which has been increasingly getting easier as we go. And that's what I'm gonna show you today. Cool, so we're gonna talk a lot about Java, which I don't really know much about at all. So you're gonna probably get a lot of interesting questions from your host today. Yes, yes. So what part of Java are we gonna talk about? So we're gonna talk about a couple of recent developments in the Java world, which are mostly micro-profile, which is a microservices framework. Everyone's got a way of implementing microservices and this group, which is part of the Eclipse Foundation decided, hey, why don't we get together and figure out if we can make our microservices compatible with each other by building them in a standard way. Cool, okay. So that's basically what micro-profile is meant to do. Okay. And it's also implemented this thing called open tracing, which is a way of tracking your performance through from an end-to-end process that includes multiple microservices. Gotcha, okay. Yeah. So we're gonna talk about those two things and I'm gonna show you how you can actually run those on Azure, on container instances, and also one of our partners, Red Hat, has an implementation of Kubernetes called OpenShift. I'm gonna show you how to do that as well. Oh, that sounds fantastic. Yeah. All right, let's get started. Okay, so basically, what's on the slide right now is a little snapshot of the community that is actually working with micro-profile. Some of them actually have, they actually have implementations already created, including Red Hat. Red Hat is a microservice implementation called Thorntail. So they've taken the micro-profile standard, which is the Eclipse agreed upon standard, and they've made a reference implementation of it, and they've called it Thorntail. I love the names in the Java community. Yeah, yeah. Chances of those names. This is the only one that actually has some kind of cool name. All the other ones are like, there is a spring offering, which is just basically spring microservices, and some other ones as well. But yeah, this one's the only one that came together and said, hey, let's get a brand and a name. So we've got Thorntail, micro-profile, yeah. I hear we have a couple of Red Hat guys in the Twitch stream chat as well. So that's great. So welcome to everybody. Welcome to James Faulkner. Thank you very much for being there. And Aaron Wislang, who actually helped a lot with the demos I'm going to show today, I just want to give him a shout out as well. All right, so guys on the Twitch stream, make sure that you ask your questions. Yes. About Java and Red Hat, we have the experts here. Yep. So I did want to go over a little bit about micro-profile. Basically, there are three things that it started with, which is context and dependency injection. That's a CDI too. What you're looking at on the screen right now, that's the bottom row there. Started back in September 2016 with context and dependency injection, which is just basically a way of managing microservices. And then JSON for reading JSON and then processing REST with JAXRS. And since then they've basically evolved and they added new packages. And the most recent one is October 2018. They added a newer version of Open Tracing. So that's why I'm going to show Open Tracing today as well, because it's sort of like the latest coolest thing of the latest coolest thing. Cool. Micro-profile, so yeah. So ThornTale itself is, the idea is it leverages a bunch of Java EE expertise out there. It's an open standard and as I mentioned before, so ThornTale is an implementation that actually implements the standard that's been put together. So it's just a way of making things work. Everything works through POM, XML. So it's Maven-based and Maven-thornTale is the actual command you use. So Maven-thornTale run to actually run things. And for those of you who haven't been working with Java, this might be a little foreign in the audience, but I'll show you a little bit about how this actually works. In fact, let's just get into that now. I've got some things here. There's things about working with Micro-profile with ThornTale in terms of health probes and things like that, but I'll show a little bit more details of this fault tolerance and metrics and things later. We like real code, not slides. Yes, yes. Well, the main thing I wanna show you just before I get into the demo is to, this is the whole reason behind Micro-profile. Yeager. It's all I need to do to add Yeager, which is a implementation of the open tracing standard. All I have to do to add Yeager is just add this dependency in my POM file and it pulls all the right files in and makes it run for me. And then I can just run Yeager and look at traces of my application. So open tracing, if I may get into my browser here. So open tracing is actually an implementation that is open source out on GitHub. And it's a way of tracking multiple microservices from end to end. So you've got this thing called a trace, which is basically, I made a web app call and then I've got 10 other microservices that do things like credit card processing, inventory processing, stuff like that. And each one of those is called a span. So the microservice itself generates a span when it runs and reports back to a log file, and that log file aggregates all those spans together into a trace. So you can figure out what's going on in each one of those microservices, is that what you're saying? Exactly, exactly. So I'm just focusing on that part, but there's a ton of more features of Micro-profile that you can use, but let's dive into that. Cool. So what I've got here is a command window, most people are familiar with. All I'm gonna do is run my application, which is basically invoked by Maven Clean Thorntail Run. And as that fires up, takes a minute or two, it actually will start up, it generates a war file. And then that war file gets used by Wildfly, which is Red Hat's implementation, because we're using Thorntail here, Red Hat's implementation of the microservices standard, it's going to use Wildfly, which is basically Red Hat's implementation of the Java app server that you can use for that as well. To do that, use a war file, and the war file actually fires up. And so we're doing a build and then a deploy, and it's actually gonna run on top of this. Cool. Now while that's running, let me go, I'm gonna show you something else. I'm actually doing this all in Visual Studio Code. Visual Studio Code itself has several plugins you can use to read YAML files. For those of you who haven't been familiar with Visual Studio Code, it's an open source, free text editor that you can use. It's got a million extensions, and I've got about half a million of them installed in my machine, so I can do things like- And it supports multiple languages and Java, one of those, and it supports. Yeah, I wanted to show that. So you can actually use this for managing Java. It's not a full Java IDE, but it is a text editor, and it's great for demos like this, so that's what I use. It's good for like quick editing of files and things like that. Is that what you're saying? Exactly, exactly. And it's great for editing things like YAML and actual markdown files as well, which is what this is. So while that's running, let's just check back to see if that finished. Yep, thorn tail is ready. All right, let's fire that up. So some people in the audience might be familiar with this. This is the application that we decided to build for this just because it's fun. It's Minesweeper, what we call it, Microsweeper, and you can find it on GitHub, on Beben's Microsweeper demo. But anyway, it's just a full Minesweeper application on the back, and it actually uses- You're doing pretty good. Cosmos DB, I know. See, this is what happens when I'm doing a demo and I'm trying to do it quickly. It doesn't work. Oh, wow. You're super good. All right. And you do a couple of these. Oh, there we go. And you get the idea here. So it's Minesweeper, it's an application. Every time I finish a game, it writes over here to the scoreboard. It also writes this in Cosmos DB on the back end. Okay. So, okay, so let's go in. And the next thing I want to do, so I built this application. This is a micro-profile application that's sitting there running. Now I want to trace this using open tracing. To do that, I'm going to use the Yeager implementation. So let's go there. I'm going to use a Docker file for that. And this takes hardly any time at all to fire up. So Docker run, local machine again. So you're running everything locally here? Yes. All of micro-services, everything is running locally. Exactly. What is Azure? We're going to get to Azure. No, that's cool. But right now I just want to show how this actually runs. And then we're going to actually deploy this out to Azure Container Instance. So this is Yeager. So Yeager is a way of visualizing traces, okay? So open tracing is the actual service. And as you can see here, there's nothing that's been found. So if we play over here with some more games of microsweeper, there we go. You'll see a couple of traces in there in a minute. Each time that something is saved to the scoreboard, there's a trace that happens. Another great game though. I know. That's of course more of his loss. This isn't when you want the regular games. But anyway, let's refresh this. So over here, we're actually going to find some traces. As you can see, Yeager query is now lit up. So the basic traces you get are Yeager queries and Yeager query is just something that actually runs and checks to see if Yeager is running. Okay. It's like a health check? Yes, basically. And here's the, this is a trace. Actually, no, sorry. This is a span. And then the trace is this end to end thing. And basically the way this graph works, and it's a very simple graph. This is the free version. There are other versions of open tracing implementations out there that you can use that are a little more robust, but this one's just the basic free one. And if this circle is larger, that means the actual trace is taking longer. If it's up higher, like this one, that means the actual span is taking longer. So the whole end end process. So that's what we're looking at here. So that's just basically Yeager running locally. And there's a bunch of environment variables you can set in Yeager to actually display things a little more granularly. And I'm going to show that in a minute with some of the details that we said. Yes. Yes, so let's go in. Let's continue on. So that's just running locally. Let's fire up a, I'll skip over the properties for now and I'll show you a demo of those properties later. But the next thing I'm going to do, I'm going to just take this. So in Visual Studio Code, I can fire up a window, a bash window. Let me just close that one, because I have to use that one. And basically this is Windows subsystem for Linux. Okay? So I've only, I've been at Microsoft for a while. Yeah. But most people at Microsoft are not familiar with the Windows subsystem for Linux or using Visual Studio Code for Java and things like that. I live in kind of a totally different world. It's starting to change, but for now it's sort of a very different from what most people are used to seeing when they're working with Azure. And in this case, what I'm using here, I just hit control back tick in Visual Studio Code. And it actually fires up a Windows subsystem for Linux window inside my Visual Studio Code. And that actually is a full implementation of Ubuntu Linux bash running on top of Windows. And you can run that from your command line. You can just open a window. Or if you have it already installed, you can actually set it up here and run it as well. It comes with Windows 10. It's free. Try the box. Yeah, it's out of the box. That's cool. But yeah, so basically control back tick. I've got mine set up for Windows subsystem for Linux. And then I can actually execute some commands. So let's go up here. I'm gonna set some variables first. See, now I mentioned Aaron before. I'm gonna call Aaron out again. Aaron was like, thank you for setting up this particular script for this demo. He wrote it on a Mac. So as you can imagine, when you run a batch script on Windows, it's harder. But if I use Windows subsystem for Linux, I can just fire this up. I set all the same environment variables and everything. So I'm actually in a batch environment. And it works just as well as it would on the Mac. Thank you. So we're gonna create a resource group. Bup, bup, bup, bup, bup. This takes a minute. So as a resource group, like you mean like an Azure resource group? Yes, yeah, we're saying an Azure resource group. So by the way, I'm doing all this live from scratch. Nothing pre-baked. Yeah, no, this is really... And basically that's what we wanted to show in this particular demo. Awesome. So you're just sending commands to Azure. Yeah, so I'm actually just right now sending commands to Azure through my Windows subsystem for Linux image. I've already logged into my Azure account and it's set up. So I created a resource group and then I set up an Azure Container Registry, which is a private registry you can use. People who work with Docker are probably familiar with Docker Hub. And that's a public registry. You can pay extra on Docker Hub to have private repos, which means you, just like GitHub, where you actually store private Docker files that you have sitting there. Azure Container Registry is a paid service on Azure that you can use to actually store private containers as well. And the reason why I want... Images are... Yeah, private containers, private images. The reason why I want that is because I have a Cosmos DB connections and things built into this application that I don't necessarily want to share with the public. Right. Yeah, so basically I set up an easy ACR create the actual ACR. Now, this is a cool one. Let me start this off because it takes a couple of minutes. So this is an easy ACR build. And this is built on top of Docker build. And what that does is it's actually going into... Let me show you the Docker file here. This is actually, it's gonna take a little while to run. But while it's running, basically what it's going to do, it's going out to Maven and it's getting a JDK8 from Maven, okay? And it's gonna build some applications using some directories and things. It's gonna build a Maven clean package for this. And then it repackages the whole thing after it's compiled using the open JDK8 Alpine image, okay? And this is what's called a multi-stage Docker file. And the reason why you want to use a multi-stage Docker file is size. So the Alpine image of Java 8 is much smaller than the Maven image. You need the Maven image to actually run and build and compile all this stuff because you need Maven. But then once that's done, the Java itself, we just need a basic Java image to run. And the cool thing is, you don't need Java or Maven installed on your local machine because it's all pulling it from Docker. So it's pulling it from the Docker hub using these images, Maven 354, and then open JDK8 Alpine. It's actually pulling those down. So if I wanted to, I didn't do it today, but if I wanted to, I could run this on my Azure shell. For those of you who haven't seen this, shell.azure.com is a pretty cool thing. It's actually a full bash environment on Azure. There we go. So let's take a second to start. There we go. But I have my Azure CLI on here. I have Cloud Foundry. I have Terraform. I have all kinds of things built into this shell. So I can actually go out to shell.azure.com from any computer, from that dodgy computer in the hotel lobby, and I can actually do stuff here. And this is the coolest thing. So I wanted to show this, that other thing takes a couple of minutes to run. So this is Visual Studio Code, an implementation in shell. So I can actually do things. Here's the same code that I was working with. Where is it here? There we go. Here's the same code I was working with. You don't get all the interpretations of every file. Actually, it does yaml. So it'll actually work with all the files here. And I could have actually run this technically from here as well, just as well as I could run it on my local machine. Yeah. So this is actually some pretty cool stuff people might not know about. It's right in the browser. And by the way, there's an app on Azure as well. You can use an iPhone app or an Android app, not to run code, but just to run the shell. So you can actually go into Azure Shell and do that as well. That's awesome. So yeah, yeah, it's pretty cool stuff. Let's see here. All right. From there, let's see what we got here. Hey, good, it's successful. So the actual build was successful. Let's go in and we gotta continue on. That was the slowest part of this demo. So, good. So now what we're gonna do is we're actually gonna get some credentials. So we're gonna get some credentials here that actually allow our Azure Container registry to talk to an Azure Container instance. So there we go. That runs, takes a millisecond. All right. And that should be real quick. All right, so that's done. Okay, so there's a little bit of a script in here for creating a single container instance, but what we wanna create is actually multi-container instance. So I'm using, I talked about Azure Container registry as a private registry. We're actually gonna deploy what we just built into Azure Container instance, which is a, if you're using something like Kubernetes to run your applications, that's great, but it takes a lot of work and maintenance and a management plane and load balancers and stuff like that. It's an orchestrator. Yes, orchestrator. So we have Azure Kubernetes service, which is great. But if you just wanna do like a little test or maybe a demo on a live stream, then we have this thing called Azure Container instance. And one of the things I learned, actually recently about this, hat tip to Erin again, is that you can, I was picturing Azure Container instance as something that just runs one container at a time. And if you, so if I wanted to connect my microsweeper application that I showed you to my Yeager application, I would have to have two Azure Container instances. That's actually not the case. I can use one Azure Container instance and put multiple containers in it. Oh, I didn't know that. Okay. Cool, because like the name kind of makes it sound like it's a container instance, like one. Yes, yes. So in essence, what it is, it's kind of like a pod that you can use, like a Kubernetes pod if you're familiar with those, that you can use to actually put multiple containers. And in this case, because we have two things running the same container, it's like running them on your local machine where they can talk to each other. So Azure Container instances are good for what type of applications, like you don't want to go full blown, like Kubernetes, like you said, what are they good for like running like batch jobs or things like that. Yes. At night or like you would normally do, but you can do them all the time now or what kind of scenarios would they, like besides your demo. For container instances? Yeah. They're really, really just good for firing things up quickly and testing them. And testing them. Okay. Yeah. So I can run this whole thing end to end in about four minutes, in a normal circumstance. But if you want to set up Kubernetes, even on any platform, not just ours, but any platform, it's a lot more work and you have to worry about manifests and you have to worry about load balancers and applications and interfaces and ports and all kinds of things. This thing is just really, really quick and dirty, if you will, a way to set up a container. I want to just run this container. So if you have something you want to share with a customer or a colleague or something like that. I see. And you want to make it sure it runs before you share it, you can just fire this up and then send them a link and say, here's your container instance running. Cool. That's the kind of thing I think is the best use of this. Gotcha. Yeah. You can't say it works only on my machine anymore. Yes. Yeah. It works on everybody's machine. It works on Docker, that's it. So basically what I'm gonna do here is I'm actually gonna build a custom YAML based on the variables that we put together. So let's start with copying our deploy ACI YAML. So the thing called deploy ACI YAML is just a way of, it's a really simple manifest and I'll show you an example of what I've done. And then we're gonna set up the custom images here. So basically what it's doing is it's taking all the environment variables that I created earlier and it's putting them into a YAML file that we can use to deploy. And if we can do a cat here or we can actually just literally open the YAML file now. And it's basically got all the information we have a location for this ACI instance, the image that we're gonna use from our ACR instance that we created or Azure Container Registry that we created. The name of the service is Micro Sweeper. And then there's a little bit of information here. I did mention the environment variables. So there's environment variables that you can use in Yeager to customize your processing of that. Gotcha. And in this case, there's just three that we had to do as a minimum. And then you start up, this is the image we're gonna use. Yeager tracing all in one latest for Yeager. This is actually coming from Docker Hub. So we've got our custom image which is coming from our ACR as this one here. And then in the second container, we've got our Yeager image which is coming from Docker Hub. And once we actually run this, it's gonna set all this up, it's gonna open some ports. These ports are used for communicating between the traces and spans and the different agents and things that Yeager uses to talk to open tracing. And by the way, you can find all the more info on the Yeager implementation on Docker Hub. There's all kinds of images there and then links to the GitHub repos for those images as well. So much more detail. That would be a session all by itself. So there we go. So that's that. So we actually created the YAML file. And we're actually gonna go ahead and just use that YAML file right down here, deploy ACI YAML. So AZ container creates, gonna create our image. It's gonna use the resource group we specified. It's gonna use the name of the Azure container images that we created. And it's gonna use that YAML file to actually generate everything. So let's just go ahead and do that. And this actually takes a very, very small amount of time. So one question while we're waiting, really quick skull crusher for life. Thanks for sticking around all day, dude. Not a Java person, but can you save a trace if you detect a problem to sort of replicate the problem and then troubleshoot it knowing all the steps it took? Yes, yeah. So basically by default, open tracing keeps everything. And you actually have to set flush intervals if you wanna actually get rid of anything, which is a good idea because it'll store things in a variety of backend data sources. But the main one is just HBase that it uses, which is an in-memory database in the backend. And you have to flush that every once in a while. Otherwise, it'll just start to get really slow and actually slow down. It doesn't slow down your application because it uses UDP. It just actually fires these things off into the ether, but it will, you won't get the latest stuff in your traces when you try and visualize it. So basically, yes, the opposite is actually true. You have to worry about getting rid of some of these versus collecting them, so, yeah. Yes, there is a demo of OpenShift coming up. There is a question there. Oh, yes, yeah, yeah. There is a demo of OpenShift coming up. Yes, there will be. Stay, stick it here. Real quick. And I've got everything all nicely tied together, so I hope you like it. Okay, so we created our instance there. And then basically what we're gonna do here is just show the image. So we've got two things that were created here. And basically this just shows that everything happened. So everything started, everything's normal, good. I won't go into the logs. The logs, we're gonna go into the open tracing part of it anyway. So in this case, I'll just grab the IP address for this particular Azure Container instance. And once again, this is just a script. It uses JQ to actually grab the IP address from the properties that are returned by Azure CLI call, which is Azure Container Show. And then, let's see, open the application. There's the application IP address. And there it is. Once again, we've got our microsweeper app. Okay. And then we wanna actually show the Yeager so that is and port 16, 686 by default, 16, 686. There we go. Takes a second to start up. Now this time, because we had some environment variables set up, microsweeper. You remember it was Yeager query before? Now microsweeper is the name of the actual application because we named it through the environment variables. So then we can find traces and there's just a couple of traces that I clicked a second ago. But the idea here is because this is an Azure Container instance, everything's in the same location for you. Gotcha. Which is nice. Okay, so that is basically everything running on a container. So as you can see, this is kind of the steps you would take when you're working with an application. You would work on it locally on your local machine, running it using IntelliJ or Eclipse or Visual Studio Code. You'd make sure it works and then you wanna deploy it out and share it and see if it works on a container. Build your Docker file and then build your YAML file to deploy that. And then just run it on Azure Container instance in this case. Now we could take this, we could build a way more complicated manifest that actually deploys us out to Kubernetes. Okay. Or some other container-based technology. Red Hat also is one of our partners and they've created OpenShift which is a Kubernetes implementation which not only manages, it's not only orchestrating the containers but it also manages your code and stuff like that. Oh, cool. So let's go ahead and show that. I already set that up. And we use the OpenShift Origin image which is actually a open source license-free version of this. And as you can see here, we've been playing it a few times trying things out. But this is the actual OpenShift. So this is Micro Sweeper. And this is actually a live IP address out there. So people can go there right now. They can go and play right now if they want to. And basically when they hit that. I see if your app's good. Boy, okay. I'm winning today. You're winning a lot, yeah. Anyway, that's what happens. So anyway, it generates the image, it stores it on Cosmos DB. So let's actually look at that. Oh, and then I'll show this. So this is the Micro Sweeper app. This is where the Yeager query is. And you can just refresh that and you can find traces. So there's a trace I did just a few seconds ago. And as you can see here, one of them is just not performing terribly well. So if this is a real app, you'd want to try that out and see what the issues are. Okay. And let's just look at what that actually took to create. In this case, here's our OpenShift implementation. The actual deployment itself is under applications deployments. And we have Micro Sweeper, Jenkins is built into OpenShift. And then we have the Yeager implementation here. And if I go into the Micro Sweeper app, okay. So if I go into environment variables, I've set multiple environment variables for Yeager. So I really tricked this one out basically with all the environment variables we need. And this is actually one of the cool features of Micro Profile. Is there's code, there's Java code, you have to write that, but then you have your Palm.xml, which manages a lot of things. And then you have the environment variables, which you can use, build into your Palm.xml, or you can actually use them per deployment. So when you deploy this, if I deploy this, I could have different versions of this that behave differently based on the environment variables that I set up here. Gotcha. Yeah. And not to make it too much of a Red Hat demo or a OpenShift demo, but we do have builds built into this and pipelines. So that's kind of nice. And the pipelines themselves will deploy things automatically. They run some tests and things like that. So the idea here with Red Hat OpenShift is it took Kubernetes and then they take a version of the application that I've got running Micro Profile. And they do special things with my Micro Profile app. Okay. Special cloud native things like back pressure circuit breakers and all kinds of cool cloud native application features built into this. So just wrapping back to the beginning with our actual application here, if I look at the Palm.xml in Visual Studio Code, let me see here, Palm.xml, inside the Palm.xml, I've got all kinds of things for health checks and things. And these run fine when you're running them with Thorntail. But then there's other things like circuit breakers and things that are just built in automatically. I didn't have to configure them in here. They will actually run and process based on properties inside OpenShift. And is that also because you're using a standard? I mean, you're using a standard. Yes. So I'm using Micro Profiles. And so it knows how to hook into all of that stuff. Exactly. So that's the idea. And that's kind of the promise of Micro Profile itself. So it's an independent open standard. And the idea here is Red Hat can write an implementation that of Kubernetes, which is another open source standard. And they can actually adapt that application based on the common language that they're using between. So we can take Kubernetes, we can write some Micro Profile features and then those can run. So another app server like Tommy Tribe can do similar things when they're handling Micro Profiles. Gotcha. And other app platforms. So it enhances the life expectancy of these microservices. It does all kinds of stuff for you to manage them. Right, yeah. So it helps with scaling and management of your actual application and things like that. That's actually really cool. Yeah. That's neat. So that's basically the session that I have put together. We watched three things. We watched Micro Profile running locally and then Azure Container Instance and then showed you the same thing running on OpenShift. Awesome, all right. I don't think we have any more. Oh, we do have one more question right here. Can we use Visual Studio 2019 to develop Java FX projects? Oh, Visual Studio 2019 doesn't handle Java necessarily. I mean, you could implement any Angular or JavaScript-based portions of that project, but to do the whole thing together, you'd probably want to use an IDE like IntelliJ or Eclipse. Typically, Eclipse or IntelliJ is really the IDE. Yeah, NetBeans. I shouldn't be. Okay, all right. People are gonna be mad at me so I'm gonna mention NetBeans. I actually remember that from a long time ago. So VS Code is good. It's very good for quick editing and especially all of these files. It has nice syntax highlighting. Yes. Editing experience. You can still edit your Java stuff, but you really typically use a full-blown IDE just like .NET developers do. They usually typically use a full-blown IDE and that happens to be Visual Studio for .NET, but it happens to be Eclipse or IntelliJ for Java. Yes, so Eclipse is sort of the open standard. They have a free version. IntelliJ has a free version, a community version, but they also have a paid version that a lot of big enterprises use. Fun fact. Most enterprise Java developers, which is most Java developers, run on Windows machines. Interesting. Yeah, yeah. Everyone thinks it's sort of like the Mac world. So the development environment is usually Windows? It's usually a Windows operating system and then on top of that, they're either running Eclipse or IntelliJ or NetBeans and, you know. Deployment is in the Linux. Deployment. So there's a lot of different features inside of Eclipse or IntelliJ that help you manage your project interactive, breaking down projects into different segments and sharing information back to, usually a Jenkins server for CI. And then we also have Azure DevOps, which works really well with Jenkins. Yeah, we're gonna ask that. You know, like so we, I mean, Edward's here earlier talking about Azure DevOps, but a lot of great features for Java developers in that area as well. Yeah, no. So of course, the big one is free private Git repos. Yes. That you can use to build, you know, on other platforms which are Git based, you have to pay for private repos. For us, you don't. And then building pipelines, of course, big advantage is if you're working with Azure on Java, you already are authenticated with your Azure account when you're working with your projects in Azure DevOps and it's easy to build pipelines and things. In fact, I wrote a blog a while ago that shows integration of. Cool. Yeah, it actually shows integration of Jenkins, the way that you can play off Azure DevOps strengths and weaknesses. So let me. All right, while you're looking it up, we have one more question came in here. What is your favorite VS code, or what are your favorite VS code plugins for Java? So if you wanna pull it with VS code and Java, what are the top five plugins you need? Let's go through my extensions. There you go. Let's go through my extensions. So Azure CLI tools is a big one. As you can see from this, I use CLI a lot. Terraform, if you wanna use Terraform, debugger for Java is a very good one. That'd be handy. Yes, there is actually a Java pack. So there's an Java extension pack right here that actually downloads all of the essentials for working with Java. And then there's some stuff on top of that like the CLI and Terraform, things like that that I particularly like. Red Hat's Visual Studio code plugin for Java is actually the main feature that everything else is based on in our extension pack. So as you can see, we work a lot with Red Hat when it comes to Java. Yeah, they're awesome. Yeah, they're really good, but inside. We actually work a lot with them with Donet too. Yes, yes, yes, I'm steel-tell. They're actually also a technical steering group from Donet Foundation too. Yes, yes, that's great. Well, Brian, this is super informative for me. Honestly, I'm really happy that we have actually a lot of great tooling support as well as Azure support for Java developers. You've really opened my eyes a lot to that, which is great. Anything else you wanna say to the audience out there? No, just try out our offerings for Java. Okay. And let us know. We really value your feedback. You can contact me on Twitter, Bbenz. And we actually have a Java CDA handle as well, which is Java underscore CDA. And a few other, we have a whole team that's working on Java that we've been building things. We'd like to know what people think out there in the Java world. See if we're on the right track. Make sure that we're building things that everyone's looking for. Cool. And yeah, definitely would love some feedback and let us know how we're doing it. Try stuff out. It's easy to use. You don't have to learn a lot of new things. There's some things that add value that you can learn, but you don't have to. You can use everything as is that you're already used to ranking with Azure as well. Cool. All right, Brian. Thank you so much. All right, so. Thanks.