Join Nate Barbettini for an in-depth discussion in this video Server architecture overview, part of Deploying ASP.NET Core Applications (2017).
- [Instructor] In ASP.NET four, your only choice was Windows and IIS server. With ASP.NET Core, you have many more choices for how to build and host your applications. There are three choices that you'll have to make for your application. Which framework to build against, which server to host with, and how to expose that server to the internet. ASP.NET Core can run on the Full .NET framework or .NET Core. .NET framework is Windows only, while .NET Core is cross platform between Windows, Mac, and Linux.
If you need to maintain compatibility between older libraries written for.NET, you'll need to use the full .NET framework, and your application will be limited to only running on Windows. Otherwise, using .NET Core means that you have the option of running your application on any platform. ASP.NET Core applications themselves run as a self contained console app on top of a server library. If you've developed self-hosted OWIN applications with ASP.NET in the past, you'll find this familiar. The server itself contains the code that translates raw HTDP requests into the structures that ASP.NET Core can work with.
ASP.NET Core ships with two servers, WebListener and Kestrel. WebListener is Windows only and currently in preview, while Kestrel is a cross-platform server that runs again on Windows, Mac, and Linux. Microsoft recommends using Kestrel even on Windows. It's been highly optimized and it's incredibly fast. However, Microsoft doesn't recommend exposing Kestrel to the public internet directly. It doesn't yet have support for stuff like load balancing, modules, or dealing with all the weird edge cases that can occur with public internet traffic.
That's where a reverse proxy comes in. If you're hosting on a Windows machine, you'll set up IIS as a reverse proxy to Kestrel. Likewise on Linux, you'll set up a proxy like NGINX or Apache to sit in front of Kestrel and forward requests. This way you have the best of both worlds. A mature server like IIS or NGINX, taking requests from the internet in a fast light-weight HGDP server like Kestrel, actually running your application. I'd recommend using the full .NET framework only if you have legacy concerns.
Like third party libraries that haven't been ported to .NET Core. Otherwise, using the cross platform options gives you the most flexibility. For most ASP.NET Core applications, the recommended approach is to use the .NET Core framework, the Kestrel server, and an IIS or NGINX as a reverse proxy. The next step is to decide on a deployment strategy for getting you application onto the server machine itself.
- Setting up your ASP.NET project
- Setting up IIS
- Creating an IIS site and app pool
- Publishing your app with Visual Studio or the command line
- Deploying to Azure
- Deploying to Linux
- Deploying with Docker