 Don't you wish you could just focus on one microservice instead of having to drag in the whole set of microservices and all of those related dependencies and Kubernetes? Well, it turns out you can. So join me and Nick Greenfield on this episode of Visual Studio Toolbox. Hey, everyone. Welcome to Visual Studio Toolbox. I'm your host, Leslie Richardson. And today I'm joined by Nick Greenfield, who is a program manager on the Bridge to Kubernetes team. Welcome, Nick. Hey, how's it going? Thanks for having me. Yeah. Nice to be here. It's a very smoky day out, but enough about that. The cool thing is that I hear there's this new feature available as part of Kubernetes called Bridge to Kubernetes. Can you tell us a little bit about what that is? Sure. So Bridge to Kubernetes is an iterative development tool for developers that are authoring microservice applications that target Kubernetes. It's offered as a client experience in both Visual Studio and Visual Studio Code through extensions that you can pick up in the marketplace. So what are some of the existing approaches that are kind of similar to Bridge to Kubernetes that can help address that issue? That's a good segue as to this next slide that I have here. So there's a lot of different tools and methods for solving these kind of challenges where you're working on a single microservice in the context of a larger application. And we've kind of categorized all those different methods and tools into three main buckets. There's the local approach, the remote approach, and then the hybrid approach. So that's these columns that I'm showing here. And the rows are key characteristics that we've learned are really important to developers when trying to be successful in their day-to-day task of developing their microservice code. And to go through these quickly, and I'll talk about where Bridge to Kubernetes falls into one of these categories, but starting with the local approach, the local approach really revolves around I'm running my code locally and I'm satisfying all those external dependencies on my local development machine. So whether I'm using stubs or mocks to fulfill those external dependencies, or if I'm actually running all those external dependencies on my development machine and configuring and connecting to them manually, or if I'm even using a system like Docker Compose to run those dependencies in containers, ultimately what this approach does is it allows me to work on my dev machine where everything is running on that workstation. And this has a lot of great benefits as in everything's local, so I get a really speedy developer interloop experience, but it does lack in that my dev machine is most likely going to be drastically different to the deployed environment where this code is ultimately going to be running in Kubernetes within Azure. So the extreme of the local approach is moving into this remote approach. And there's tools that basically allow you to write your code on your local machine, but then when it comes time to debug and test end to end, you take those changes and deploy them and sync them into that deployed environment. So into Kubernetes, that might be running in Azure. And this kind of plays off the weakness of the local approaches that I get that fidelity to a deployed environment, because I'm testing and debugging where this thing is ultimately going to be running. But now I have these extra steps in my developer interloop cycle of having to build and deploy my code. And I think working in the space for a little bit, the biggest learning that we've worked in customers with this specific to this approach is that it does add some extra friction onto a developer's workflow, because now they have to have these operational concepts of having to bundle their code and build an image of their code and deploy that image into Kubernetes. And what we've learned is that not all developers are accustomed to those sort of concepts and complexities. So the last approach, and this is where version of Kubernetes falls in is the hybrid approach, where it's kind of the best of both worlds. Ultimately, what this approach allows you to do is write your code on your development workstation, but connect to external dependencies that are running in some remote environment. So I'm actually fulfilling all those external dependencies by connecting to my Kubernetes cluster, let's say running in Azure, so that I can leverage the whole end-to-end workflow. But the only thing I'm running on my developer workstation is the code that I'm working on. So diving into that approach, this is really where we feel is like the best of both worlds. And we're seeing this resonate with customers quite well. So if you're interested, I will show you an example of how this works on given that sample application that we were just talking about. Yeah, I do like demos. Cool. So at a high level, when you are using Bridge to Kubernetes, like I said, you are only responsible for running the one work, the one microservice on your development workstation. So taking that example that I had earlier where I have that Bikes microservice open here, which is one of these back-end APIs. The first thing you would do with Bridge to Kubernetes is create a connection to your cluster. So in this case, I have now had, I've created this bridge to my deployed environment. And once this connection has been made, I can actually pick from all the available services running in the cluster which of these I want to work on locally. And so in this case, since I have Bikes open, I would actually select the Bikes microservice. So could I pick multiple microservices if I wanted to? Or one at a time? Nope, you could pick multiple. So you'd have to have different instances of VS or VS Code open, but this would allow you to redirect multiple at once. Gotcha. So when I select, in this case, the Bikes microservice, we're actually putting this redirector in place so that when I make a request that goes into the front end of my application running in AKS, it will continue to hit all the services running in my cluster until that Bikes service is called. And at that point, that request will be routed to my development workstation or the version I'm running locally. That's really cool. So it's kind of like you finished a jigsaw puzzle, and you're just kind of sticking in the missing piece when she go to run test deploy all that jazz. Exactly. Nice. So this is at a high level how Bridge to Kubernetes works. And, you know, I'd love to show you an example of, you know, our visual studio experience working on this exact application, how you could go from zero to using Kubernetes on, you know, a project that you have of your own. Yeah, let's check it out. The first thing that I want to show you is that application running in AKS. So is that bike renting application where, as I mentioned before, you can log in as a customer and you can have a list of available bikes that you could reserve for a period of time. So in this case, I would see the men's cruiser. Looks good. I can rent this bike. And then when I'm, you know, done using this bike, I can return this bike and it's returned back to the system available bikes to rent. I'm just really simple application, you know, just for demo purposes, right? So yeah, so what I want to do is I actually want to work on one of these services. And since I'm going to show you the VS experience, it's probably appropriate that I show you the reservation engine, which is a microservice that is written in .NET Core. Sounds good. So switching over to VS, I have Visual Studio 2019 open. And you'll notice that I have a solution that has one project open. And this is that reservation engine, that microservice that's responsible for actually reserving the bike. And you'll notice that over here, this is just the source code for that microservice. There's no Docker file. There's no Kubernetes configuration. It's just that source code. So you don't have to sit through opening up the giant project containing all the solutions you don't need, except for the one, right? Right. So it's just that one microservice, nothing else. Cool. And so now since I have this open, and if I go to the VS marketplace and I install the Bridge to Kubernetes extension, what will happen is I'll have this new launch profile that's available for me to use up in this list of launch profiles that I can select from. And when you select the Bridge to Kubernetes launch profile, the very first time you'll be presented with this dialogue that I have open here. And what this dialogue really allows you to do is define the connection from your development machine to your target AKS cluster where you can select that service that you want to redirect to your local running version. So just to quickly walk through what's required here. So a subscription is required. And within that subscription, I have available clusters that I could select from, in this case, these are Azure Kubernetes clusters. And then I have a filter because I have a different namespaces within that cluster. So I'm going to select the namespace that's running this application that I want to start debugging. So my bike app is running in the bike app. My bicycle application is running in the bike app namespace. Within this namespace, I have a list of all those services that I saw from that diagram earlier. And I want to select one of these that I want to redirect to my locally running version. So as I mentioned, I have the reservation engine open. So I'm going to select the reservation engine here. And this next dialogue here, the dropdown is basically asking me to select a launch profile that we want to clone. So this app is a launch profile that I'm familiar using with this microservice. And what we'll do is we'll clone this launch profile with some extra configuration that's taken from the Kubernetes cluster. Okay. Is that just to make sure that your local content is in sync with the rest of? Yeah. So the reason I'll be calling is we want to tap into how you're familiar with developing. So if I'm used to developing this application locally, however, that may be whatever profile that I have set up and configured, we want to allow you to continue using that, except we'll add some additional configuration into that launch profile that is from the Kubernetes environment that allows you to talk to those other services. So it's basically continue doing what you were doing before, but we'll throw in some extra configuration for you to use, to use the Berkshire Kubernetes functionality. Neat. Yeah. And these last two, this is actually a really neat feature that we just released. I'm really excited about. And I don't know if you picked up on how we're redirecting traffic to your development machine, but that's become problematic when you're working in a shared environment, right? Yeah. So if I have other developers that are working in that same namespace on, you know, other micro-prolaces are the same one that I'm working on, potentially we will step on each other's toes because their traffic will get set to my machine and vice versa, right? We have this isolation mode, which allows you to work in isolation where only your requests that are being sent will get redirected to your machine. And we do that by giving you this special URL. In this case, we'll prefix your URL that you're normally using for your application with your username on your machine and then this unique hash here. So that only traffic that's using this URL will get sent to your local running version or the normal URL that everyone else would be using will continue to run and hit the service that's running in cluster. That's really cool. So ultimately, there might reach a point, of course, when you do need to like push changes and things, right? So you're still going to have to fix merge conflicts in that context, right? But as far as running and testing with the Kubernetes cluster, it's not going to be an issue and you're not going to bump into somebody else who's also trying to access the same cluster at the same time. Right. So if I was working in a shared namespace, you can imagine that if my friend John was using the same namespace and working on a different microservice, he would have his own special URL and I would have my own special URL so that our traffic isn't conflicting with each other. That only my traffic is getting redirected to my machine and his traffic is getting redirected to his machine. Great. Only all traffic was like that. So at this point, I have this configured. And like I mentioned before, this is a one-time configuration that you would set up when you're getting started with the bridge to Kubernetes. We persist this. You can always go back and change it later. But for this case, I'm happy with it. So I will hit OK. So we'll check to make sure that we can actually isolate that service and we can redirect it to your local running version. So this usually takes us a couple of seconds. Cool. And that's done. That checked past. So now, if I want to start working on this service and hit some break points, let's do that. So I'm going to open up a file here. This is the bikehelper.cs and since I'm debugging the reservation engine microservice, so when you reserve a bike, this is the service that will get executed. I can actually put a break point and let's put it in this reserve bike method that seems appropriate for this service here. And then since I'm targeting that bridge to Kubernetes launch profile, I can add five. And what it's doing is going back to that diagram that I showed you before is at this point, it's creating that bridge between my developer workstation and that Kubernetes cluster. We do require admin privileges on the client machine to allow that traffic to be sent back and forth. So that is one dependency that developers will have to have when working with bridge to Kubernetes. Gotcha. So at this point, what it's doing is it's establishing that connection. It's finding that service in the cluster that I want to redirect to my machine. And what it's doing is it finds that service, it's putting that redirecter in place, and then it's going to make it so that any request that hit that service will actually get set to my machine. So I just got my UAC prompt, so I authorized that. Great. All right. So it looks like that connection has been made. It's starting my debug session here. As you can see that URL, that special URL that I had in that dialogue, when my debug session was started, it actually launched that URL. So here I am with my application and you can see I have that special URL that was provided to me when I clicked I wanted to work in isolation. So at this point, I can try to debug my service in an end-to-end scenario. So I'm actually hitting the services that are running in AKS at this point. So this is the front end that we'll call the user microservice. Here we go. And now that I have a list of bikes to choose from, I can select a bike. And again, all of this traffic is still happening within the cluster. Nothing's being redirected to my machine yet. But now when I'm actually going to reserve a bike and it's going to actually send a request to that restoration engine microservice, you'll notice that that request will get set to my VS instance. You see VS just popped open and now I'm stuck at my break point where I can debug and step through the code and, you know, however my debugging practices, I'm open to using whatever debugging practices that I'm familiar with, right? Cool. So it's essentially skipping over the existing microservice that's up in the cluster and just redirecting to your local. Right, exactly. And this is right. So I can iterate on my code. I can make changes. I can debug, you know, maybe use potential issues. And then again, the only thing here that I want to call out that is, you know, for me is the most exciting thing about this feature is that I'm only running that one microservice. I don't have all these other services. I'm leveraging them from running in that Kubernetes environment. And again, no Dockerfiles, no HelmChart for Kubernetes artifacts. I'm running this natively on my death machine. Yeah, that's so cool. I mean, even locally, sometimes when trying to look at a huge project, but you only need a chunk of it, it's just like, I'm spending all this time debugging this other issue that's not even my responsibility. Yeah, yeah, all these other dependencies. Yeah. So that's cool that you don't have to worry about that. Yeah. So, so at this point, you know, as a developer, I'd step through this code and when I'm happy with it, I can hit resume and that request will get sent back into the cluster to be completed. And the really nice thing about this is that, you know, if let's say I actually make a change as a configuration change that I would need to restart my debug session. So if I was to exit my debug session here, you'll notice that I'm no longer in that debugging mode, but I have this yellow banner up here, this info bar that says, Hey, your service reservation engine is still being redirected to your machine. So when I, so I can make a, yeah, I can make a configuration change. And, you know, I'm ready to f5 again. And what's going to happen is it's actually going to skip that connection. Yeah. When we went through initially, we're already connected. So there I am, my application launches and I can rate my code as I would. That's great. It's almost like it got cashed someplace and telling me to use it again while you're in the same BS session, right? Right. So yeah, that is the visual studio experience for bridge to Kubernetes. That's really exciting. I think that could save people a lot of frustration. So based off of that, are there any existing limitations that you want to tell viewers about? So base limitations. Well, we're working really hard to unblock any limitations. Yeah. We're working with developers or understanding the applications that they're developing and, you know, where we're rich to Kubernetes fits and really just kind of understanding the different scenarios that we need to support. I would say the one thing that we get asked constantly that I'm really excited to announce is that people want to use bridge to Kubernetes on Kubernetes clusters that are not AKS clusters. So a mini cube cluster where it's basically running your Kubernetes cluster on your development machine. And we are in the process of actually enabling a public preview that would allow you to work to use bridge to Kubernetes on any Kubernetes platform. So that's a really exciting announcement that will happen very near future. That is really cool. And speaking of previews, how can people access this tool? Is it available yet? Yeah. So we recently just went GA. So that's really exciting. Congratulations. Thank you. I have some, there's some quick starts under the BS code documentation under the develop with Kubernetes. And we also have some getting started material under the BS Visual Studio container tools documentation. I will absolutely provide some information on how to get started with those. That is fantastic. And so you already mentioned that you're working to expand bridge to Kubernetes functionality out to all Kubernetes platforms. So what else is next for Kubernetes? So I think, you know, again, it's really understanding what the scenarios that different development teams have to use. So actually one limitation that potentially when people are watching this video will no longer be a limitation is that it does is only targeting Linux containers in Kubernetes. And we've heard that there are a lot of development teams that are in this hybrid scenario where they're running Windows containers as well as Linux containers. So we want to make sure that we cater our tools to all different situations. So we're really working through, you know, we're having this ability to work and target any Windows containers. That is very exciting. Well, thanks for sharing that. That is a really cool tool that I think can help a lot of people out. I really like that you can just segment the microservice that you need and don't have to worry about anything else seriously. How much time, right? Like how much time gets wasted just trying to figure out how another chunk that's not really your problem connects to the piece you're working on. So super exciting. So yeah, thank you. Yeah, thanks for being here, Nick. And yeah. And so go try it out. It's GA now officially. Yeah, we want to know what you think. So we'll provide some information on how you can get in touch with our team, and we want to hear about your experiences with the British Cooper, so absolutely reach out. Awesome. So until yeah. So until next time, happy coding.