The Future of .NET in the Server: ASP.NET vNext optimized for Cloud and Server workloads
Before getting into “The future of .NET in the server”, I want to highlight how the ASP.NET and Web Tools teams just released great RTM ASP.NET stuff (final version). Specifically, Improvements to ASP.NET Web Forms and many other new features for ASP.NET in general, all of that final/RTM as part of Visual Studio 2013 UPDATE 2 RTM, released during this week in TechEd NA 2014.
But, in this blog post I want to focus on the “Future of .NET and ASP.NET”. A sneak peak or preview of ASP.NET vNext and .NET vNext in the Server.
The ASP.NET and .NET teams joined forces for this effort, and are taking advantage of the great innovation at the .NET core, like the .NET Compiler Platform (“Roslyn”), and impressive improvements in the runtime/CLR and framework especially made for server workloads.
So, this week, at TechEd NA North America (May 12-15 2014), we’re announcing the next generation of .NET on the Server, a new wave of ASP.NET vNext and .NET vNext in the server. These news are about early previews (ALPHA) and it will be evolving during the upcoming months (therefore, many things could also change). But, this is the first public disclosure about “the future of .NET in the server”, like I said.
ASP.NET vNext is an evolution of ASP.NET. Everything you know today about ASP.NET will apply to ASP.NET vNext. You can use the existing libraries or the new versions for those libraries in .NET vNext and get immediate benefits.
However, modern web development demands a simple, lean development experience built on top of a composable framework.
Below I show a diagram that I made for the TechEd announcement, summarizing the future of .NET, where ASP.NET vNext focuses especially on the “Cloud optimized” area (right-below), with pillars like high throughput, small foot-print, side by side execution and “cross-platform enabled”. I’ll drill down on those topics in this post.
Then, focusing just on ASP.NET vNext, you can see below a simplified ASP.NET vNext stack diagram.
A very important news to highlight is that MVC, Web API and Web Pages now share a unified core, they are merged, in fact. For instance, there’s now a single type of controller. This will allow a much better and unified developer experience. This includes:
- One routing system, one model binding system, one filter pipeline, etc.
- Smooth transition from Web Pages to MVC
- Return HTML as views (HTML) or data (JSON or XML) for HTTP Services.
How is ASP.NET vNext optimized for the cloud and server?
We’re adding a cloud-optimized (public cloud, private cloud, any cloud, or you can also say server-scale specialized) version optimized for server scenarios like low-memory and high-throughput.
These are the main pillars of .NET vNext and ASP.NET vNext (cloud optimized):
• Slim .NET stack optimized for cloud and server workloads based on:
– Optional small Core CLR that only contains fundamental building blocks
– Support of true side by side execution of the framework (even self-contained per application), that allows breaking changes scenarios
– Enables best-of-breed performance and scalability with a high resource-efficient optimization
• Seamless and “by default” integration with Microsoft Azure and Windows Server through simplified configuration. There won’t be different configuration for each environment, that’s why it is “Cloud-First driven”.
• Rich ecosystem of composable NuGet packages. Libraries and even the CLR are now NuGet packages! 🙂
• Open Source accepting contributions!
• End to end decoupled stack (ASP.NET and .NET) based on Dependency Injection, so the same ASP.NET application could be running on different CLRs and even different platforms/OS.
• It will be cross-platform enabled (Windows plus other different OS like MAC and LINUX supported by MONO), thanks to its mentioned decoupled nature and openness.
The following stack diagram shows how these“cloud optimized” features applies to ASP.NET VNext (not taking into account cross-platform characteristics, just yet):
It is important to note that currently, the ASP.NET frameworks that will be “cloud optimized enabled” with that optional slim and lightweight stack, will be MVC, Web API, Web Pages and SignalR. Since ASP.NET Web Forms will still be coupled to System.Web, it cannot be part of this “cloud optimized” stack. But, Web Forms is in any case part of ASP.NET vNext, too, and will provide many new features and innovation in the next version, as well (like we just did in VS UPDATE 2 and new features for Web Forms).
Also, current plug of the Core-CLR on top of IIS is “Helios”, but there will be an IIS Native Module in the future, too.
How will I be able to adopt ASP.NET vNext in my new applications even when my servers are running older versions of .NET?
The goodness of ASP.NET vNext is that you’ll be able to have business applications with certain sub-systems running on the established ASP.NET and System.Web and other newer sub-systems running on the new ASP.NET vNext, all within the same server and IIS infrastructure or self-hosted in your own process.
Therefore, ASP.NET vNext will let you deploy your own version of the .NET Framework on an app-by-app-basis. One app with new libraries can’t break an app “next door” with a different version. Different apps can even have their own cloud-optimized CLR of their own version.
This is why it is a true side by side execution, when using ASP.NET vNext, different applications can use different versions of the framework without affecting each other and each application runs against the framework it references and deployed with (self-contained, like XCOPY). By using the side by side execution of ASP.NET vNext, you decide when you adopt .NET updates on an app basis (as opposed to machine basis).
NuGet packages go “mainstream”
NuGet is going mainstream in this new wave of ASP.NET. The CLR and cloud-optimized libraries are NuGet packages!
Something cool is that without changing references in your code, you’ll be able to swap a NuGet package (like the folders below within my application) to just its related source code (like OSS source code related to any NuGet package) and your application will work the same way, directly, no need to change references at all. For example, , let’s say NuGet package CompanyX.CoolLib has a bug but you were initially using just the NuGet package. Then, you realized that this NuGet package is OSS so you could grab the code and debug it!. You just need to make a folder called CompanyX.CoolLib in your local project and put the source code you got in that folder. This is great for open source projects. That local version of source code overrides the original NuGet package, allowing you to easily patch bugs locally in libraries while you wait for a new release. When a new fixed NuGet-distributed version shows up, update the version and delete the local source. Isn’t it cool! 🙂
Therefore, each ASP.NET vNext application needs to describe its dependencies to packages. For that, the project system is also changing – we’re integrating packages.config, NuGet specifications (nuspec), and project files (csprojs) into a unified view of your project dependencies expressed in a project.json file.
NuGet packages and class libraries are treated the same. You get full intellisense in the project.json file and NuGet packages come down automatically and transparently. Below I show an example of the JSON file defining the project references/dependencies (named Project.json):
"dependencies": {
"Helios": "0.1-alpha-build-0530",
"Microsoft.AspNet.Mvc": "0.1-alpha-build-1115",
"Microsoft.AspNet.RequestContainer": "0.1-alpha-build-0512"
},
……
Example: The same application running Side by Side on different framework versions
Here I created an example of a Hello World ASP.NET vNext MVC app that I’m running self-hosted (web server in a console app), where I’m running different framework versions per execution (it is even the same code).
This alpha includes command line tools for running and managing ASP.NET vNext apps. That is what I used in order to select the framework version I want to use from each app.
The "kvm" command allows me to control my environment. I run "kvm list" to see what versions of the ASP.NET vNext are available. I can switch between them on a per-environment basis:
C:\>kvm list
Active Version Runtime Architecture Location
------ ------- ------- ------------ --------
0.1-alpha-build-0420 svr50 x86 C:\Users\cesardl\.kre\packages
* 0.1-alpha-build-0420 svrc50 x86 C:\Users\cesardl\.kre\packages
0.1-alpha-build-0421 svr50 x86 C:\Users\cesardl\.kre\packages
0.1-alpha-build-0421 svrc50 x86 C:\Users\cesardl\.kre\packages
I set the active version with "kvm use version" and opened two command prompts, setting different CLR and .NET versions in each.
You can also see below, that I have several framework versions available in my machine and I could run my app on any of them:
Or, the selected framework could also be self-contained by my application, so I don’t need to require any framework installation in any server before I can deploy my application.
Why should I use ASP.NET vNext? What are the benefits?
Depending on your application scenarios you may benefit of some or most of the features provided by .NET vNext in the Server, as explained below.
Cloud optimized scenario: High performance for web applications and services
As organization that needs to scale out to thousands of concurrent users, ASP.NET vNext (cloud optimized) will provide best of breed in performance thanks to its light and optimized architecture, while leveraging high scalability based on its small resources’ foot-print (minimum amount of memory required) and optimized related light frameworks for data access (Entity Framework vNext).
Fast/agile development and deployment scenario (Modern Web Development)
As cloud developer, frequent deployment to the cloud is very common. ASP.NET vNext allows fast development with an optional way of working that goes this way: “Change C# code, save .cs file, refresh browser”, with no explicit compilation required in Visual Studio. This is handled transparently in the web server environment (either development machine or server) thanks to a fast in-memory compilation performed by the .NET Compiler Platform (“ROSLYN”). As I mentioned, this is optional. You can also compile and deploy the assemblies, but for development scenarios is pretty straight forward.
This scenario is very convenient for development/testing stages with a high rate of changes. You could even use a browser-based code editor (like “Monaco” in Visual Studio Online) to make these live updates (“Change a C# .cs file in your site, refresh your browser” experience).
Updating C# code into development machine or dev/staging web server
With that, we achieve the following features:
Quick code changes and site updates:
• Fast iterative development – modify code and refresh the browser in near real time
• Leverage dynamic in-memory server compilation while developing
• Developer can change a controller (Web API or MVC), refresh their browser in <2 seconds without an explicit build in Visual Studio.
• App can be edited in “Monaco” (cloud)
• App code can be published to Azure from a source code repository (VSOnline, etc.)
After running an ASP.NET vNext application, you could take a look to the /Bin folder, and you’ll be surprised!. It is empty!
NOTE: This is not just ASP.NET Websites, or Razor View compilation – this is any C# code, any C# class library, compiled in memory in the moment you run the app and it realizes it has new C# code. (Of course, if you want to deploy assemblies/DLLs on disk, you can do that too.)
This new way allows to use any text editor, like Sublime, or a simple Notepad!. But, of course, Visual Studio will provide the best end-to-end development experience.
No friction when moving to the cloud
Moreover, by using ASP.NET vNext, all features will work by default in Azure and Windows Server in the same way (session, cache, storage, security configuration and cloud diagnostics) so as a developer I don’t need to think about “the cloud way” if I’m moving an app to the cloud, it just works by default in the cloud and on-premises with no changes required depending on the environment. This approach makes it easier to transition from an on-premises application to an Azure cloud app, as the ASP.NET frameworks and API are completely unified.
Application density increase per server for multi-tenant and high scalable cloud-based organizations
As organization based on the cloud (public or private) or web hoster offering multi-tenant services, one of the main goals is to minimize the amount of resources required to run the apps (servers and persistence support) by increasing application density and resource utilization in data centers.
By supporting ASP.NET vNext (cloud optimized) applications, the organization can drastically have a more efficient support of large numbers of applications thanks to the new .NET vNext light footprint and optimization for server workloads.
The organization can also deploy zero-day patches as needed to ensure the hosting environment stays secure.
Improved Entity Framework vNext: Lightweight data access framework
Even when EF can be used from any environment or application type, the new EF vNext is very related to this new wave in .NET and follows the same principles. It is also a very lightweight Entity Framework with a much smaller footprint.
Main features in EF vNext related to ASP.NET vNext:
• Lightweight/modern data stack
• Designed for server and cloud apps. Also for any device (Windows Phone/Store)
• Leverages existing API skills and development experience
• Easy to move most existing apps
There will be other additional features about EF vNext that I’m not mentioning here, related to devices and different types of data sources.
Cross-Platform development (Mac and Linux based on “Mono Project” implementation)
Any organization who is building products running on the server will be able to develop ASP.NET vNext web apps or services using different operating systems (Windows, Linux or MAC OS X based on “Mono Project”).
The following is a simplified diagram of how ASP.NET vNext is cross-platform enabled thanks to its end-to-end use of dependency injection across the stack:
ASP.NET vNext is Cross-Platform enabled
You can see below how I’m running a ASP.NET vNext MVC application on a MAC thanks to MONO:
While Mono isn’t a project from Microsoft, we’re collaborating with the Mono team in order to make this possible. It’s our aspiration that it "just works" on other operating systems.
ASP.NET vNext is decoupled from the underneath platform thanks to its end-to end use of Dependency Injection across the whole stack. A few details of DI in ASP.NET are shown below.
Dependency Injection and IoC Containers in ASP.NET vNext
• Built-in DI for configuring services/libraries
• Environment specific services can be configured through dependency injection
• You can still wire up your favorite IoC container
• Admins can locally patch an application without requiring the application to recompile, and with negligible downtime to the application.
• Applications are not locked into a patched version – newer versions of patched components can still be used
• Since Dependency Injection is applied end-to-end thru the .NET stack, that enables cross-platform to ASP.NET vNext, like mentioned (Windows, MAC, Linux).
These are the main principles used to shaped the new runtime:
-
The runtime should be as self-contained as possible. Until the runtime has walked the application dependency tree of your application it cannot know which of the Core CLR packages you want to use, so it cannot load any of them before that. Except for Roslyn, since the dependency resolver that uses Roslyn doesn’t actually load Roslyn until after the dependencies have been walked.
-
Dependency Injection through the entire stack. DI is a core part of the Runtime, and all libraries we build on top of it.
Openness
At the end of the day, you’ll be able to opt in or out of the cloud optimized framework for compatibility, or the libs you want to use, or even the tools!.
The next version of ASP.NET is modular and all about choice. your choice of operating system, your choice of framework, your choice of tools/Editor.
It is all about openness.
But, of course, on top of these foundations we’re introducing, Visual Studio will continue to provide the rich IDE experience for ASP.NET vNext that has made ASP.NET with Visual Studio a great environment for developing compelling web sites, apps and services.
And the deep and broad range of investments in .NET we are making bring one of the most exciting moments in time for the .NET ecosystem, as a development platform.
GOOD TIMES FOR .NET! 🙂
RESOURCES about ASP.NET vNext
Currently, you can just use the COMMAND-LINE tools available in the links below. There’s no public Visual Studio tooling available, but ASP.NET vNext tooling will be available pretty soon, in a few weeks (June 2014 timeframe), probably.
TechEd North America 2014 sessions focusing on ASP.NET vNext
INTRODUCING: The Future of .NET on the Server (By Scott Hanselman and Scott Hunter)
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B385#fbid=
DEEP DIVE: The Future of .NET on the Server (By Scott Hanselman and David Fowler)
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B411#fbid=
Microsoft Development Platform – Foundational session (By Scott Hanselman)
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/FDN05#fbid=
This last foundational session covers a lot more than .NET in the Server. It covers the whole end-to-end Microsoft development platform vision, including devices/apps development, Azure scenarios, etc., rather than just .NET in the server.
Bits/Code and early alpha Documentation
Deeper details: https://github.com/aspnet/Home/wiki
Bits and OSS source-code: https://github.com/aspnet/KRuntime
Getting started: https://github.com/aspnet/Home
Additional links on .NET vNext
http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-generation-of-net-asp-net-vnext.aspx
http://www.hanselman.com/blog/IntroducingASPNETVNext.aspx
Light
Dark
0 comments