 Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Brady Gaster. Hey, Brady. How's it going? Good. We're going to talk about containers and microservices. So this is Episode 4 of our five-part series on the Smart Hotel 360 app. Exactly. We had previously done the overview, we talked about the website, we talked about the mobile apps, and today we're going to talk about the guts of the matter, the microservices running in containers, running on Azure, and these microservices are basically what does all the work. Pretty much. Whether you're booking or looking up rooms or notifications or whatever. We have a bunch of this code. Tell us a little bit about the architecture. What does it mean to be a microservices app? How do microservices and containers play along? This whole stuff here running in a Kubernetes cluster in Azure Container Service. We can talk a little bit about that. We are going to do a toolbox show that is more of an introduction to containers. That's going to come out in a couple of weeks. But in the meantime, tell us a little bit about this. I can do that. So really what we did when we set out to build the Smart Hotel 360 stuff was to show a couple of things. Was to show obviously all of our technology and how awesome it is, all of our tools and all that goodness. But what we also wanted to show was sometimes you build an application, and then you have to build a second application augment it, and over time you get a developer who's good in technology, X, Y, Z. Things we get a little bit crazy. You might have a Node app, a Java app, a .NET Core app, a .NET Framework app, everything. The nice thing about is the point that Robert touched on here. I'll do it with my mouse. This area is that these are all the individual microservices that we've got. And in this case, running up in a Kubernetes cluster in Azure. So what makes it a microservice as opposed to is any? Is any service a microservice? Well, that's a really good question considering how we architected this. Robert knows that's a very hot button question, what is a microservice? It depends on who you ask on what day of the week. But to me, and I'm only going to say this from my perspective, to me microservice is a thing that you can build, that's a self-contained unit of code that does one thing. In the case of our architecture, we've got one that allows for searching the hotels. We've got an API that does some interesting configuration stuff, which we'll talk about later on. We've got the notifications API, task API, and all kinds of different things. Nice thing about all these APIs is that they literally run inside of a cluster. One thing that we talked about earlier was why we didn't put the app service inside of the cluster. We already had that public web app and we basically started bringing things that were in the smart hotel 360 architecture into Azure. So basically, sort of like you take your code and put it in a box. In lay person's terms, rather than just having a project that does all these things, booking, suggestions, sentiment, profiles, discounts, instead of having it one project, sitting in one service. One giant solution. One giant solution. We've made a WCF service, we've made a web API, but instead of having it as one big thing, all written in the same language, all by one or a small number of people. Because that happens like so never. In a real environment. You could say, well, let's break it down into individual pieces. The word micro is, it doesn't necessarily mean micro in terms of, it does one thing, it only adds, it doesn't update. It's not quite like that. You're breaking down these feature areas into their own services and then putting those into containers so that you can swap them in and out and scale them individually as needed. And then the Kubernetes cluster part is basically orchestration. It's what's running these containers of services and managing them. Now, one thing that's always been impressed upon me, I like the way you define microservice, it's not like one line of code. It's one unit of your kind of your overall topology or your overall enterprise and you want it to be totally self-contained. With that self-containment comes not only the code and the dependencies that the code needs to run, but the environmental dependencies that the code needs to run. For instance, if I wanted to run, let me look on my ribbon here. If I wanted to run PowerPoint, I would need a full blown OS. I would need some sort of a graphics card. I would need a lot of stuff. If I want to run an ASP.NET web API, I pretty much only need the.NET Core runtime, ACTP stack, that kind of stuff. So the idea behind the container is it's the bare metal that only the pieces that you need for your app to run given no other surrounding circumstances. This cluster part, which I think is interesting is if you're outside of the cluster, if you think about the cluster almost like a network. If I wanted to make a call to you, I would just say, Mac, Mac, Robert, MSFT, laptop, and it would go directly to your machine. But if I was outside, I would have to know the full DNS address. So each one of these services can communicate with one another just by saying bookings API or sentiment API or whatever, they can just communicate independently. But one thing I do want to point out here, we were talking about this out in the lobby a moment ago. These microservices don't just have to be code. We actually have microservices running that run SQL server on Linux. And that run, help me say it, you know, always screw it up. Postgres SQL, I can't say it, it's a listy thing, I can't get it right. But what we've got over here, this is the smart hotel 360 repository that we've sent you to throughout the other shows. If you scroll down, you'll see that we have this backend services link. If I scroll down in this, you'll see that we have some pretty great instructions with screenshots of how to do everything. And I'll kind of walk through what I've already done and what I would use the tools to do at this point. So I've already done a Docker compose build. What that'll do is that I'll bring down the base images that I need to. It might bring down the ASP.NET base image for the core stuff and node base image, etc, etc. It'll bring all that stuff down and then I'll deploy everything to it. And then I would use Docker compose up commands to actually do everything. In this case, what I would do first, I'll talk to people who've said, I'm being OCD about it, we're friends, I'm OCD. It's a part of the poison here. Is that I would definitely want to have my databases online first. Now I know that I could do that in my Docker compose and it would take care of everything, it would orchestrate everything. But when I'm doing it on my local machine, I'm just picky about it. So what we've done is we've given you two sets of commands that you could run that would actually bring everything up into your local Docker and you could party on it. Now I'm using VS Code in this case because there's some really awesome extensions for Docker and for Azure within VS Code. And also because if you go back to where you just were. Yep. To the architecture diagram. Sorry. Some of the services are written in. Java. .NET Core. .NET Core. Summer in Java, summer in Node. Exactly. Obviously the .NET Core ones could have been written in Visual Studio. Exactly. Could have been written in Visual Studio Code. The Node ones, same. The Java ones, not so much in Visual Studio, could have been written in code. JetBrains doesn't matter, you may have it. So rather than bounce back and forth between Visual Studio and Visual Studio Code, we're just going to do the entire episode today in Visual Studio Code. Exactly. I think you have some surprises coming later with Visual Studio and later shows. I know you've done a couple of other Docker shows as well. I'm going to do probably a two-parter on containerizing existing apps. Like you've got a web forms app, you've got a WCF service, right? Containers are not just about core and non.NET languages. In fact, they're absolutely not about .NET or non.NET. The idea behind a container is just a container. It's the bare minimum I need to run whatever code I want. We're going to do a couple of episodes in a couple of weeks or so that are containers with .NET framework apps. And then sometime in the future, Steve Lasker probably, although it could be somebody else, will come on. But I want to get Lasker on to show us some enhancements of Visual Studio that make it easier to work with this type of scenario where you've got a bunch of container, a bunch of services in containers that talk to each other. And you might have written these two, but to test the application, you need to be able to talk to all of them. There's some tooling that was shown at Kinect that is coming out in the future that will make that easier. So we'll do an episode on that. Cool, that would be exciting. That would be good stuff. But back to the present. Oh, back to the present. So back to the VS Code stuff. What I've done is I've gone into the Visual Studio Marketplace, which is where you can get all the extensions for Visual Studio that our good friends work on in the building across the street. You can also get extensions for VS Code. And what I want to point out is that there's actually an Azure category, and you can go out there and you can find a bunch of great extensions. There's one for App Service, so if I want to deploy my ASP.NET apps or my Node.js apps up to App Service, I could do that. You can access Cosmos DB using some pretty handy extensions. And then the one that we'll talk about a little bit today, if I can find the whale, is right here, this Docker extension. So that's what I'll be using today. Now the nice thing about both VS and VS Code is that both tools make it really easy for you to do things like work on your Docker Compose file, which I'll open up right here. I would get handy IntelliSense directly from within this tool or from within Visual Studio that makes it a lot easier for me to actually create these Docker Compose files. I'm not good at these files. So I usually have to lean on somebody or lean on the tools. And so again, the Docker Compose file. The Docker Compose file effectively, what you can see here, you'll see this term Services. Then you'll see the Bookings API, the Hotels API, just like we saw earlier on the architectural diagram. Each one of these guys live over here. So if I were to expand this particular folder, this is Profiles, you'll see this is a CS Proj. So that's a.NET Core app. However, if I were to go down here and expand into Reviews, you can see there's a Palm XML, that's a Java app. Okay. So we've got a bunch of different architectures running here. Now the Java apps in the Node app, they actually reach out and they make a connection to the PostgreSQL database. Yeah. And then a couple of the other microservices will actually reach out and talk to the MSSQL database that's also running in a container. So again, the Docker Compose file. It's sort of your orchestration file. It says, here's our network, here are the machine names. I want to call each one of these things. What you can also see is the Docker file. So if I were to look in the Docker file for the bookings API, we would see right here is the Docker file. And it's basically going to tell me which image I would want to pull down from the registry, how to go ahead and get started. So this file takes an image sitting in a registry. It could be the Docker registry. Basically, it could be Docker Hub. Or it could be Azure Container Registry. It could be anywhere. Brings that down and then builds the container locally with things you need. Well, builds the image locally. Builds the image. Image locally with things you need. So in this case, it's going to bring down ASP core. And then it's going to actually install the actual service into that image, which would then be able to run locally. But then you want to push it out somewhere. Exactly. And you can run publish. Exactly. And you can see here that we'll do in the front build as publish. And then we do the run.net publish. That actually just takes that publish image, like you said, and just puts that into the container. Now if we wanted to, I could use the Docker stuff right here. If I expand this, you'll see I've already done a Docker compose build. So I've already got all of my images. So the compose is just basically the equivalent of the build across the number of services. Exactly. It's like I have this whole enterprise with the services. Build each image individually. Correct. Compose will build them all for you. That's correct. It'll build them all for you. And if you were to author your compose file, again, this is beyond the scope of my knowledge, I admit. But if you were to write that Docker compose file in such a way that you build everything in the right order, like you build your SQL and then your Postgres SQL and then yada yada yada, then you wouldn't have to do things like from the command line the way I do. Of course, if you're OCD like me, you probably still would do it in order from the command line. But that's just me not trusting everything. So what I'll do here is you'll see that I've already got these images inside of my VS Code tools. If I were to expand containers, it's expanded. But there's nothing there. Because I have no containers running on my computer right now at all. So what I'll do at this point is I'll flip over to my bash prompts. And you'll see that I've got Docker compose up, which will basically compose all those Docker images that I've got and bring them in and turn them on. Basically wakes them all up. And you'll see that I'm launching SQL data, reviews data, and task data. So I'm going to bring up my SQL server and my Postgres SQL databases. Containers are all running what? Linux or Windows? Linux. Happen to be Linux? Yep, they happen to be Linux. We could run these in Windows, I believe. I know the SQL one you definitely could, but why not? It's containers. So we can see that we've already got all our images running. The build would take a little bit longer than that. Now if I flip over here to the tools. And you're running locally at this point? Because I'm running locally. I'll flip over here to the tools and refresh this. We should see there's the containers that I've already got running. So you see that I've created the two Postgres SQL and one SQL server on Linux. So we've got this guy running. And over here, I'll do Docker compose up. And what you should see is that it'll go ahead and start compiling everything or not compiling where I did that with the build. It'll go ahead and launch all these images up. You'll see Spring run by, because that's our Java app that happens to be running. If you were to look closely, you would see some .NET tracing that's coming, as well as some Node.js tracing. If I'll flip over here to this guy, you'll see that my terminal window where I have the Docker compose up with the database images, you can see that now the apps are actually, the individual services are actually reaching out and talking to those databases. Now if I were to show you real quickly, if I flip over here inside of our code, you'll see that we've got this configuration service. That's actually one of the services that we sort of like glue in there for that app service that we have. So we have the public web app. Since the public web app is actually written in .NET core, if we wanted to, we could package that up and containerize that as well. We've put that in the app service that we already had that running out there. We saw no reason to do that, but when we started bringing all these services up into our Kubernetes cluster, now we've got an app service outside of that cluster that needs to reach in and make communications to the APIs. As you remember from the show with Maria, we talked about how that app actually is a spy app that uses, what was it, React to communicate back and forth to the microservices in the backend. So what I'll do here is I'll actually go up to localhost 6103, and you'll see that I've got this localhost docker. That's because we might have multiple configs. In this case, I've only got one. This is my local configuration. If I was gonna deploy this up to Azure, I'd probably have a second config file here. And the idea behind this is all of our apps can just reach out to that configuration's URL. And once it does, we can see that my app service app would reach out and it would reach out to this configuration URL. It's gonna say, I need to know how to get to the hotel's API. I need to know how to get to the bookings API, et cetera. Since this is really my development environment, this is my localhost file, I might have another file out there that was my ACR file or my staging file, just for each individual environment where I've got this stuff set up. So people who want to play around with this code have three choices, run it all locally, all using localhost, which you've just now set up. You can take those containers and push them into your own Kubernetes cluster. Cluster, Kubernetes. Or you could push your images into Azure Container Registry and then you could bring them into Azure Container Service. You could also put them into Docker Hub if you wanted to use that registry instead of the Azure Registry. Or we have them all up and running at public end points that you can use. Correct, correct. And if you were to take a look at the public website, GitHub repository, that one's already pre-wired for what we call our public end points. We wanted folks in the field and MVPs and folks out there and customers to be able to just clone this code and party on it without having to deploy everything. Because the only thing you really wanna see how to use is the ASP.net site in the serverless function. You might not need all this other stuff. But if you're like me, you might wanna bring all this stuff down, install Docker locally and party on it. What you'll see that's on my screen right here is the TAS API. I've been on your show before talking about Swagger and Open API specification. We use Swagger in all these services. So if we wanted to discover them, we could do that if we needed to. Just to call out to my friends in the OAI. So, but that's kind of the smart hotel kind of the backend. This is really what we built kind of showing if you have apps that are built over time, if you have an enterprise that's being built over time and by multiple developers, multiple languages. We have the tools for a .NET developer to be able to do the stuff in Visual Studio. You could use the Docker tools of Visual Studio to build everything and deploy it to Azure. Likewise, if you're running on and on Windows environment or you're building stuff in Node or Java that you wanna use VS Code for, we've got very similar tools in there as well. We've got tools to make Docker and containers as easy as possible for you. So this is an application pattern that a lot of people are investigating, the microservices running in containers. Benefits of it. Let's just review. Gives you more of an ability to break pieces of the application up and assign them to different teams who are not necessarily all using the same language. So you've got Java developers, Node, Core and this .NET Core in this case. You can have each of them write a particular piece of it and then bring it all together. So it gives you the ability to get additional people building the app, spread the work around. You've got more separation of these things so that it's easier to swap them in and out, easier to scale them up and down as potentially needed. So bookings, the actual hotel API to talk to the hotel may be stable over time, but bookings tend to peak, have peaks and valleys, think about classic example. One other thing we talked about. Black Friday in the hotel. Exactly, scaled out or what have you. Right, so it makes it easier to scale individual pieces. Then containerizing them gives you again, the ability to, makes it easier to scale, makes it easier to deploy these individual pieces and then the Kubernetes part is just an orchestrator. Just an orchestrator. Not that that's a little deal or anything. Thank you, Kubernetes. Yeah. This is a complex topic, unfortunately. One other thing we talked about in the green room out there was the concept of SQL and Postgres SQL. So why would I want to put a database? You have databases running in containers. Right, I said well let's say you have a monthly process or a weekly process or something that just happens intermittently. You might not want that database running online all the time because you might need that database online for 10 minutes a month. So if you put that into a container image, put that into your registry, whenever that process kicks up, it would bring that image over. Now you have a SQL server running in the cloud, you do your data massaging whenever you gotta do with it, take it out. So it's good. So you would save money there too because then you wouldn't have everything running all the time. Okay, so this is kind of a modern architecture. And so, folks watching this, go take a look at the code. Again, you have the ability to run it all locally in your own containers. If you don't want to do that, you just want to run the apps calling existing services. We have them all running publicly. So you can kind of decide what you want to do here. Exactly right, all right. And we have all the shows are going out pretty soon and we'll have a nice page for you to learn all about SmartHotels 360. We'll be tweeting about- Three of the shows are up. This is the fourth and the fifth is ready to go. We've already recorded it. Exactly, we did amount of order. Yeah, I'm about that. We containerized it. There you go. Awesome, thanks a lot, man. Thanks, Brady. No problem, thanks a lot. All right, I hope you enjoyed this. Take a look at the code, let us know what you think about it, play around with it and we will see you next time on Visual Studio Toolbox. Take care and don't forget to send pull requests if you have ideas.