 Hi, my name's Lisa Guthrie and I'm a Program Manager with the Azure Dev Spaces team. Today I'm going to talk with you about how you can use Azure Kubernetes Service and Azure Dev Spaces to develop microservices running in Kubernetes. We all know that Kubernetes is great for deploying, running, and managing Cloud Native applications. But what about developing those applications? There's a lot of challenges that are inherent in building large Cloud Native applications. You have lots of microservices that allow you to scale and allow you to grow into a really large dev team without stepping on each other's toes. But it can be really hard to manage that from a developer perspective. You can't even run a large Cloud Native application, the entire Cloud Native application, on your local development workstation. As your teammates are making updates, it can be really challenging to keep things in sync or keep your mocks or your stubs in sync with the actual application. So this is where we've introduced Azure Dev Spaces to help with a lot of these challenges. Azure Dev Spaces is an extension to Azure Kubernetes Service. At the heart of Azure Dev Spaces is this concept of a shared AKS cluster for team development. You can create this cluster, you and your teammates can all collaborate and run your application within this shared cluster. This gives you a lot of benefits. It allows you to onboard new team members with really minimal setup. You don't have to install Docker, you don't have to install Helm, you don't have to clone your entire repository and know about all the dependencies that your dependent services have. You can simply install an extension for Visual Studio or Visual Studio Code, or there's also a command line interface. You can mix and match. So if you do some C sharp development and some no development, you can install both the code and the Visual Studio extension and you can use both at the same time. When it comes to actually getting the code for your application, you only have to get the code for the service that you're working on. So if you've got a service that depends on five other services, rather than trying to run those all locally on your development workstation, you can run those additional services up in your shared team cluster and just work on the service that you're actually actively developing. Another benefit here is that you can test your code end-to-end. You don't have to simulate dependencies because the service that you're working on is also running up in that shared team cluster, and it has access to all the other services that are running there. You don't have to write stubs, keep those in line with what's going on, with the actual production services. If your teammates make an update to another service, then you see those changes right away. They can put them into the team cluster as well, and you don't have to synchronize code or rebuild the service or anything like that. When your service calls their service, you automatically see the latest version of that service that's running in your shared cluster. So let's take a little bit of a closer look at how this works. So you've got your development workstation, and when you press F5, you can run that code that you've been working on up in an AKS cluster that is enabled with Dev Spaces, that has had a Dev Spaces controller created on it. You can iterate very quickly. We've made a lot of optimizations to make this process as fast as possible. So for example, if you just make a simple change to an HTML file, we don't go through and completely rebuild the container image that's running that application. We simply put that updated file up and map that into the container that's already running, and you see those changes right away. Similarly, we don't rebuild a container if you just edit server code like JavaScript files or C-sharp files. We just rebuild that particular code and then map that into the running container. The only things that really force us to tear down a container are, if you for example, change a Docker file or a Helm chart or something else that really changes the way that that container is deployed. Also, your teammates can be using the same cluster and going through this exact same process with running their code up in the Cloud, and you all benefit from having access to what you're all working on. Now one question we get is, is this how I deploy to production as well? The answer is no. We see this as really being part of that development process. Eventually, when through this iterative process, you get to the point where you feel like you have code that's really ready to go on to production, you would still check into source control, you would still go through probably some sort of CI CD pipeline or whatever your normal deployment process is. This really supplements that. It doesn't completely replace your CI CD pipelines. Another feature that really helps with collaboration is the concept of spaces. So here you can see a diagram of a small microservices based application. So there's three microservices that make up this application. Webfrontend, Employee Search, and My Web API. They're communicating with each other. And you can see that there's a URL, a public facing URL, that you can use to access this application. Now what if my teammate Susie is working on that Employee Search service? What DevSpaces allows her to do is create her own copy of that Employee Search service. And she can run it in her space or in a Dev space. Let's call that Dev space Susie since it's Susie who's working on it here. This does not replace the version of Employee Search that's running up in the team's default space. Susie has her own version that she can edit, that she can live debug, and so on. And she gets her own end point, her own public end point. As you can see in this diagram, it's the URL of the main application, but prefixed with Susie, the name of her space, and .s. When requests come in to the application on that end point, what happens is that DevSpaces looks, the request comes into the web front end service. DevSpaces looks to see if there's a copy of web front end that's running in Susie's space. Because it sees that Susie in the URL, and it knows that it needs to look in Susie's space for a copy of that service. In this case, there is no copy of web front end running in Susie's space. So DevSpaces will direct that request to the web front end service running in the team's space, in the default space. Now, if web front end calls out to Employee Search, DevSpaces goes through that same process. It sees that Susie header attached to that request. And it looks to see if there is a version of Employee Search running in Susie's space. Now in this case, there is, there's that copy that Susie is working on. So it will automatically redirect that request to Susie's version of Employee Search. This is a second end point, so if Susie's version is completely broken, or if she's live debugging it so the service is not responding at that particular moment, all of Susie's teammates can still access the team's version of that service at the normal MyApp URL. What Susie's doing in her space does not affect them at all. And then similarly, if Employee Search calls out to MyWebAPI, then DevSpaces looks to see if there's a version of MyWebAPI running in Susie's space. In this case, there's not. So again, it redirects back to the version that's running in the team space. So really important here, it's not that Susie has every copy of every service running in her space in this shared cluster. She only has the services that she's working on that are directly impacting her work. So she sees updates right away to all the other services. If somebody were to, if I'm working on that web front end service and I have some updates to web front end, and I put those in the team space, then again, Susie will automatically see those updates. She doesn't have to rebuild my version of web front end or anything like that. It's just that when she comes in on her Susie end point, she will see my updated version of web front end. So this can really help with finding problems that might normally be caught further down the line in integration testing. It's very, very easy to get these services up and running in the Teams cluster. And then you can start to uncover some of these problems. So I'm gonna show a demo of this. All right, so here I have a very simple web application that I've built. And you can see that there's an about page here. And it lists out the members of the development team that built this website. And this page is pretty ugly. I don't really like the formatting of these names and they're not in any sort of order or anything. So I've made a few updates to this website in order to show the names in alphabetical order and also in a nicely formatted bulleted list. So if I take a look at this code, the employee names are actually coming from a back end web API. And my web front end code calls this employee search API, built by my teammate Susie, to get the names of the developers. Well, this employee search service, it's actually, it's a no JS service. I'm a .NET developer. And I don't even have the no JS workloads or whatever I need installed on my machine. So I, instead of trying to grab that service, maybe it has some database dependencies as well that I don't even know about. So rather than trying to go through the hassle of setting up this employee search service to run on my local machine. I've done what lots of developers do. I have a little stub that simply returns the employee data. You can see what this looks like. So just return some JSON data and then I manipulate that in my code. So I'm gonna go ahead and run this in isexpress just like I've always done. And just make sure that this is working here. My site loads, I'm gonna click on about. And my code is going to call out to that mock service and bring back the data and then format that nicely. So this is great. I can see that I've got a nice bulleted list here rather than that ugly formatting that I had before. Plus all of these names are now alphabetized based on last name. So Martin appears at the top and going down to Simon here at the bottom. All right, great. So my code's working, but of course this is with a mock. So before I check in this code, I would want to of course change that to actually make a call out to the service that's running in AKS. So that when I deploy this service into my AKS cluster, it makes that proper call. So I'll go ahead and save this. And today, this might be where my development process ends. Maybe I check this code into source control. My CICD process kicks in to maybe deploy the code to a test environment. Maybe there are some automated tests that run against it or maybe I have the opportunity to test it manually. But I'm kind of done at this point. All I need to do is check in. But with Dev Spaces, I have another option. I can very quickly take this code, which I know is destined to run in AKS. And with just a few clicks, I can run it live in AKS. So let's see how that works. I'm going to change my debug launch target here from IS Express, where it was before, to Azure Dev Spaces. And I'm going to take a look at my debug properties, just to see how this is all set up. So in here, I'm going to have my AKS cluster name here. So this is my team's shared AKS cluster, where I'm working and where all my teammates are working as well. And I can also choose a space here. Now, it so happens that the updates to this about page are being tracked in user story 1, 2, 3, 4, 5, 6. So what my team has done is create a space specifically for that user story. It's a child of this default space. So thinking back to the diagram I showed, if any of the services that comprise this application are not running in that user story space, then Dev Spaces will automatically use the versions of that service that are running in that default space. But if there are any updated services in this user story space, then that's what will be used instead. I'll also just highlight a little change that I made to this code in order to enable all of this. You can see that this code here propagates an HTTP header called azds route as. When a request comes in to Dev Spaces enabled space, then if there is a prefix to that URL, so for example the suzi.s that we saw in the diagram before, it pulls off that prefix and it sticks it in this azds route as header. So then as the request propagates throughout the different services in the system, that header propagates as well. And that's how Dev Spaces knows that this request originated on suzi's endpoint or on user story 123456. And it knows which services to direct that request to based on that. So it's really important that when I do make a request out to another service, I make sure that I propagate this header as well in my code so that the routing works correctly. But aside from that, this should be ready to go in Dev Spaces. All I have to do, again, I don't need to have Docker installed locally. I don't need to build a container image. I don't need to create a container registry or anything like that. I just press F5 in Visual Studio. I've got the only thing that I did need to install was the Visual Studio Kubernetes Tools extension. That's the one special thing that I have installed over and above just Visual Studio 15.8. And that's what gives me this functionality. So you can kind of see in the output window here that Dev Spaces, it has synchronized my code up to the cluster and it's going ahead and it's building the container image. While it does that, I'm just going to pull up the Kubernetes dashboard here and just show you a little bit of what's going on behind the scenes. Dev Spaces is a little too quick for me there. We'll come back to that. Let's take a look at what's going on in Kubernetes itself. So here I am in the Kubernetes dashboard, standard Kubernetes AKS stuff here. And I am specifically in the default namespace which, if you remember, is that root namespace for the shared team cluster. And I've got a bunch of stuff running in here. There's Web Frontend, which is the service that I've modified the code for. But there's Employee Search as well, of course, and there's a couple of other services as well running in here in the default namespace. If I click on the namespace list here, you'll also see that there's just a standard Kubernetes namespace called User Story 123456. And if I click into User Story 123456, see what's running in here. And there's Web Frontend, and you can see that that was just started a minute ago, when I pressed F5 in Visual Studio. And it looks like my teammate Susie has also been updating that Employee Search service. So she's got a version of that running here in this User Story space. The other two services that you saw running in default, and again, it could be 20, it could be 200, depending on your application, those are not running in this User Story space. They've not been updated as part of this User Story. So if Web Frontend or Employee Search make any calls to those services, they'll go back up to the versions of those services that are running in default. All right, so let's see how this all came together. So here's my updated about page, and I can see that I've got my nice bulleted list now of employee names, but there's something wrong here, and this is kind of subtle, but when I looked at it before, when I looked at it when I was running it locally here, the list of names was sorted by last name. So Simon Winther appeared at the bottom. And now Simon Winther is somewhere here in the middle. So for some reason that alphabetization is not working. This is kind of a subtle bug, and maybe we've got an integration test that checks for to make sure that things are alphabetized correctly, but that would be a very easy thing to miss. And remember the only change that I made in my code was switching from using that the stubbed service that returned my stubbed out JSON data to using the actual live employee search service. So I've got an inkling here that there may be some sort of incompatibility here between my updated web front-end service and the updated employee search service that I could see my teammate Susie has put into our user story space. Oh, one other thing, sorry, that I should have highlighted here is the URL. So the URL for the standard or the original version of the site was just web front-end and then the usual AKS stuff afterwards. The way that I got to my updated code was that I prefixed that URL with user story one, two, three, four, five, six, dot s. All right, so great, this is great. We've identified a bug that normally, it's just taken me a few minutes to run and see this bug. Normally this would be a whole long process waiting on builds and CI CD and so on. So it's great that I've identified it, but Azure Dev Spaces even goes one step further and provides you the ability to much quickly figure out exactly what's going on with this bug. So let me switch back to Visual Studio here. And I'm running under the debugger here. Visual Studio, in addition to starting up the container image running live in my AKS cluster, it also opened up a remote debug session to that container. So I'm able to come in here and I'll just, I'll set a breakpoint here and some of my updated code and let's see if we can figure out what's going on. All right, so I'm gonna click about and I should say to here that I am choosing right now to live debug a service running in that user story space. Now the downside here is that if my teammate Susie wanted to test out her employee search service or wanted to do anything with that version that's running in the user story space, she wouldn't be able to come through web front end right now because of course I'm live debugging it. What I could do is create a child space of that user story space, maybe called Lisa and run just this service in that Lisa space and then I could live debug it all day long. Susie could still get to the user story version of the application running at the user story URL or of course to the teams version running at the default URL. But maybe I've communicated with her to let her know that I need to do this real quick. Hopefully it's just a quick bug and let's see what we can do here. All right, so when I clicked on about, of course it made another call into this code. I am now broken into the debugger and I am live debugging this service running in Kubernetes. Let's just go ahead and step through here and okay, so I'm getting my employee string and here, let's see, well, hmm, there is, let's go one more step here. If I look at full name here, now full name should have the first name and we did the split on comma, on the comma. It was expecting a list of employee names that were in the format last name comma first name but it should have put Peter's last name into the zero spot and Peter's first name into the one slot but it looked like it didn't do that. In fact, it looks like maybe the format of this data has changed. So rather than employee here being set to toth comma Peter, it's Peter toth comma. If I go back and looked at my stub data, I can see that it was toth comma Peter. So here's the problem is that employee search has apparently changed the format that it's using to return that employee name data to me and my code just needs to be updated in order to accommodate that. So just go ahead and continue here. When this comes back, I can just really quickly stop debugging and I'll just change this. This will be a little bit quick and dirty but I'll just change it to be a space delimiter and then I'll switch all these zeros to ones and ones to zeros. That explains why the alphabetization was off because it was alphabetizing based on the full name. So like Peter toth rather than just toth. All right, this looks good. I'm still gonna, I think I'm just gonna still have a trailing comma there at the end of the name but I will just at least make sure that I've identified the right problem here. I'm gonna warn you, I've been having DNS issues today and I'm a little concerned because it said in my output window here that the public DNS name was pending registration. Okay. So it's not pulling up here. I'll take a question and we'll come back to it and see if that DNS, the public DNS endpoint has gotten properly registered. Let's see, so we've got a question that Microsoft promotes AKS. Which orchestrator is better to create a microservices solution? Azure service fabric or AKS? That's a great question and it's one that we got a lot and I guess the answer is both would be my answer. It really depends on what you're trying to do. Each both AKS and Kubernetes in general and service fabric have different strengths and so certainly with AKS, a lot of people like that Kubernetes is open source and that there's a great community around Kubernetes, a lot of improvements that are being made within that community where sometimes we see people leaning towards service fabric or preferring service fabric is for example, if you have legacy Windows applications running on the .NET framework, you're not ready or maybe you're not able to migrate to .NET Core and Linux. You don't really have any options there on AKS. Today AKS is Linux only that of course implies .NET Core from a development perspective. So we see a lot of people looking at service fabric when they're in that situation. Service fabric also has some additional features such as stateful services that appeal to people just depending on what their application needs and what some of the requirements are. So they definitely coexist. They're both wonderful orchestration platforms and we're seeing tremendous adoption in both spaces but there's just some differences depending on what you're trying to do and what some of your preferences are. All right, let me see if our DNS has come back here. No, unfortunately it's not come back to show the update but hopefully you got the picture that I was able to very quickly run that my code in AKS. I was able to really do a full end-to-end test across my applications. So not just my service running with data that I had massaged myself but actually using data coming from other services. And you can imagine too if maybe the answer here rather than me updating my code was perhaps to go to my teammate Susie and say, hey, why did you stop returning data in the common delimited format? If Susie were to update her code I would see those updates right away and that would be another solution besides just, besides me updating my code. There are any other questions I can take those. I will also switch back to my slide deck quickly here and I just wanted to make sure to put up the URL for our documentation on Dev Spaces. So just a word on sort of where we're at. Dev Spaces is currently in public preview so you are welcome to go out. You can try everything that you've seen here today and everything that you need to get started is at this aka.ms slash get azds URL. We do have tutorials for .NET which I know is really interesting for this audience or what this audience is probably going to be mostly interested in. And again, you can either use Visual Studio as I was showing today or you can use Visual Studio code with .NET Core. In addition, we do have first class support for Node.js and for Java. Java is just recently announced or we just recently put that support out there so you're some of the first to know about that. And what I mean by first class support is everything that you saw me doing here today with being able to live debug services and press one click from Visual Studio or Visual Studio code to get code up and running in Kubernetes. There is also a command line interface for Dev Spaces and that can be used with any language. So another piece that I did not show today was that we have commands to create your Docker file to create your home chart for you so that you don't have to muck around with that or even know anything about those files. And that piece only works with these three supported languages right now with .NET Core, Node, and Java. But for example, if you had a go app and you already have a Docker file for it and you've already created a home chart or gotten it up and running in Kubernetes, you can use those artifacts to run that application in Dev Spaces as well and to get all of the routing features there. So as you saw in my demo, I said that I had this service that I was interacting with which was a Node app and I didn't have to ever build that or run that. It was just running up in my cluster and the same goes for absolutely anything that you can run in an AKS cluster. Yeah, so definitely check out the documentation here if you're interested in playing around with Dev Spaces. We've got quick starts and tutorials to walk you through the whole process. I'll wait a few more minutes to see if there are any other questions coming in. Otherwise, yeah, we can wrap up. Looks like that's it. All right, well, thank you very much and I hope to see all of you going and trying out Dev Spaces.