 Hello, I'm Paul Yukinovich, Lead Product Manager for Azure Dev Experience. This year, there's just been an incredible uptake of containers in the industry, in services and in distributed applications. It totally makes sense because it helps us get density, it helps us make more portable applications with dependencies, and it really speeds up that end-to-end DevOps pipeline. Visual Studio 2019 also upped its game adding all kinds of tools to make you productive, adding containers to things as simple as individual services all the way up to complicated distributed applications using Kubernetes. Let's go check it out. So we're inside Visual Studio 2019. What I want to do is create a myriad of different services ranging from really simple all the way to a more sophisticated distributed application. Let's create a new project. We'll choose ASP.NET Core. I want to create a web front-end. I like MVC. We'll turn on HTTPS and let's get going. So at this point, this is business as usual. We have a web application loaded in Visual Studio. I can run it inside of IAS Express and have that really fast interloop in Visual Studio. What I want to containerize, what I would do is add Docker support. We'll take the defaults, and really all that does is we add a Docker file to the project. So that tells us how to build a Docker container. One thing to know, Visual Studio by default in debug mode, it'll really use this first from statement. The rest of this is used by the release configuration, and typically in a CI CD pipeline, that's where these different stages are important because we'll build a release package and then we'll finalize, but we'll actually get rid of all those interstitial files. That'll give you a cleaner, better, ready for release container. We also set the run target for the debugger to Docker. So I can, let's say, open a controller, set a breakpoint. Now that we've set the breakpoint, we can F5 and run inside of Docker. We'll make sure we have all the base images. We'll create a Docker image for you. We'll start that image and we'll run. We can see at this point, it is still just business as usual. We're running our web application inside of the Docker desktop environment, getting the production realism. But also when we hit our controller, we're getting full Visual Studio debugging with everything you know and love about debugging. At this point, what I can do is I could, let's say publish to the Azure Container Registry, or more often what we're seeing developer teams do is we'll set up CI CD pipelines using, let's say Azure DevOps and we will continuously deploy the source code, including Docker up to Azure. Now let's take this a little bit further. I mentioned that we can integrate with a DevOps lifecycle. One really crucial part of that is unit testing. So let's also just add a unit test the way we always do in.NET. So what I'll do is I'll add a new project. You can see there's all different kinds of tests, whether it's X unit or N unit. In this case, I'll choose X unit. I like to follow the convention of taking my project name and adding test.test at the end. We'll create that. Okay. I have a very simple test harness with a stubbed out method to test. What I also want to do is add a reference for my test project back to the original web project that I'm testing, and just for the sake of time, we'll add a fictitious test. So let's assert false and we'll pass in a false value. Of course, you would stream a real input from a method in the web app and we'll negate ourselves with a little message here. So this is the world simplest unit test that we're going to run. I can go ahead and in the test explorer, I can see that this test was created and I can run all. Cool. I can see visual studio and.net just seamlessly worked with a simple web application project that was also containerized. But in this case, I'm actually still not running the unit test inside of a container. So let's go ahead and see what that would look like. So I'm going to just use the same steps. I will add Docker support. We'll choose the defaults. In this case, I get a default Docker file. Now what I want to do is I want to run inside of a container that actually has our SDK CLI and build tools. So this runtime image that I have, that's a little bit too slim. So let's pick one that actually has the SDK, and we'll match the version number. So SDK 2.1. I like the working dir. Now what I want to do is make sure that all the files are copied into the container from my test directory. And last, I want to run a unit test. And that's just what we already know from the CLI, we say .NET test. And that's it. This again is very simple. This is something that will unit test at F5. What I'd probably really want to do in the fullness of time is I want to hook and create a test target after the build and publish happens. So when I hook up to CI CD, that's what I'll eventually do. But let's try this now. Let's run this test project as the startup so we can really see it. And you can see that the Docker build process is actually happening in the background and our .NET test layer is being run as well. And the most important thing is we can see that our test results, it flew by, our test results passed. So let's pop back over just to take a quick peek. So we can see that after this layer ran, we got that CLI output actually integrated as a part of our build process. So this can work inside of Visual Studio, this can work at the command line, this can work in PowerShell, and this can also work in your DevOps pipeline, just seamlessly integrate testing into your container workflow. And it's as simple as that. Okay, so now we have a simple service with a simple test. And I want to show you how we can even scale out a bit more from here. So typically when I think about containers, it's not only isolation to the pensies, but it's also really tiny. And that allows me to do things like microservices. And in the end, I'll have maybe many microservices or many services. So let's look at what that would be. I'm going to set this main project back to my startup. And what I'll do is I'll add another project. We'll pick web again. But this time I want a web API. And think of this, you know, this is my front end API, and maybe I'd have some workers as well. Let's call that PY API. And we'll choose the API option. We'll keep the other defaults. All right, now I've scaffolded out that web API project. And you guessed it, if I want to dockerize this project, I add docker support. I get the defaults here. And in this case, I could just run my solution with multiple startup projects like so. And notice how the solution is the startup. And this would give me two isolated containers running side by side. But at that point, there's no orchestration. And so what we see now is that there are a set of apps where it actually makes sense to have orchestration with things like service discovery, things like routing, things like load balancing. So in that case, we have some more options for you there as well. I'm going to set this back to my startup project. Make sure this one back to my startup project. And let's add orchestration. So we'll pick container orchestration support. And Visual Studio has support for several orchestrators. I'm going to pick Kubernetes and Helm, but there's also service fabric and Docker compose. So you have plenty of ecosystem options to do the orchestration. Let's add Kubernetes. And at this point, what the tooling is doing is it's scaffolding out the Helm charts in the Kubernetes manifests that are needed to run these containers inside of, not only Docker, but inside of Kubernetes with orchestration. And I would repeat that for every service that I want to be a part of Kubernetes. So let's add container orchestration here. We'll pick Helm. And at this point, I've really taken .NET applications. I've made them ready for containers and I've made them ready for Kubernetes. And a cool thing to point out here is we have a new service called Azure Dev Spaces. Azure Dev Spaces makes it easy to build and run inside of Kubernetes, inside of Azure. So you're effectively doing a remote F5. But even more importantly, it allows me, as an individual developer, to work in a team on my services without impacting everyone else in the team. So that would be the up command in Azure Dev Spaces, which we do every time you F5. So as you can see, it was really easy to start with a simple service and then just scale out from there, add more services, add tests. And at any point, I'm actually not locked in to still run as Kubernetes or to run in the Docker environment. I can actually still quite simply switch back to IS Express or switch back to Docker. And that allows me to maybe run really fast or to do things on my machine because I already have my machine set up. So I just want to point out, you really have that flexibility to move throughout this continuum and work the way that your team wants to work. So as we just saw, we were able to use Visual Studio 2019 to really leverage all the things going on in the ecosystem around containers. We have images for .NET Core, .NET Framework. We saw Linux, Windows, all different kinds of distros of Linux. And we really saw that continuum between, again, simple services using just Docker files all the way up to distributed applications using Kubernetes and Helm. Also, of course, you would expect the best in class debugger from Visual Studio. We saw that work seamlessly inside of containers. Another notable thing is, you can easily even debug Kubernetes up in the cloud using Azure Dev Spaces. And it has that additional benefit of you get isolation while testing and debugging in the cloud with your own services amongst the fleet of other services. Last, we really worked on that flexibility so that you can debug and run straight to the metal using IS Express or inside of a Docker container or inside of Kubernetes. So depending on whether you wanna be really fast or really have that production realism, you have a whole spectrum of options. We also make sure that you have the flexibility to hook into your DevOps pipeline, doing things like running unit tests, having multi-stage builds so you can control the phases and hooking well into Azure DevOps. So with all that said, what I would ask you to all do, go get Visual Studio 2019. Make sure you have the web and Azure workloads installed. That'll give you all of the container tools. Try it out, check it out, let us know what you think. Thank you.