In late 2013 we made available a prerelease NuGet package which allows running a managed web application directly on top of IIS without going through the normal ASP.NET (System.Web) request processing pipeline. This was a relatively quiet event without too much fanfare. At last month’s MVA Windows Azure Deep Dive, we spoke about this for the first time publicly to a global audience.
Today, I’d like to give a formal introduction to ASP.NET Project “Helios”. This post will talk about why we’re introducing this project, what we hope to accomplish with it, and how this might fit in to our ecosystem moving forward.
I assume that the reader has a basic understanding of OWIN and ASP.NET Project Katana. If you are not familiar with these, a brief overview can be found at http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana.
...
Why Helios?
When we look at our ecosystem, we’re pleased by the success of MVC, WebAPI, SignalR, and our other recent high-level frameworks. These are valuable tools, they have a low barrier to entry for most developers, and they’re deployed completely out-of-band. This allows us to innovate quickly. MVC and WebAPI have published new major releases annually; SignalR has approximately quarterly releases. It allows our customers to deploy immediately, even to shared hosters.
Yet because System.Web is part of the .NET Framework proper, the ASP.NET runtime itself cannot iterate as quickly as we would like it to. We are bound by the release schedules of the .NET Framework as a whole. If a developer asks us to add a feature to ASP.NET, he must wait for the entire framework to rev. And then he must wait for his hoster or IT administrator to update the .NET Framework version on the web server. And if there’s a bug he must again wait for us to provide a fix.
Our core runtime iterates on the scale of years. The state of web technologies is much more agile – much more nimble. A web technology can live its entire lifetime – conception to sunset – in the time that elapses between major releases of the .NET Framework. Our developer audience deserves a base on which they can build a new breed of modern web applications.
And it’s not just wanting more agile development. Recall the list of ASP.NET pain points from earlier: unwanted redirects, too-helpful security handholding resulting in requests being denied, and so on. We’ll never be able to make more than minor tweaks to these behaviors, as we can’t risk breaking customers who have deployed sites and are depending on the existing behaviors.
Finally, we’ll never be able to make the ASP.NET core runtime a “pay-for-play” model. We have experimented several times with moving Web Forms out of System.Web.dll and into its own out-of-band package. This would finally allow us finally fix bugs that have been plaguing us for years. But Web Forms defined ASP.NET for years. The ASP.NET core pipeline and Web Forms processing are inextricably linked.
...
Goals and non-goals
As with all things, we need to define our goals before we can determine whether we have been successful in this endeavor. It is not our intent to make a new framework that is everything to all developers. In particular:
- It is not our goal to have screaming high throughput for “Hello World” scenarios. While Helios does in fact perform significantly better than the full ASP.NET pipeline for such scenarios, these metrics aren’t terribly useful for real-world applications.
- It is not our goal to provide 100% compatibility with existing applications. In particular, Helios projects do not support .aspx or .ashx endpoints or other ASP.NET-isms.
- It is not our goal to compete with self-host for developer mindshare. Each OWIN host has its own benefits and drawbacks, and developers should choose the host that meets their needs. We’ll discuss choosing a host later in this post.
On the flip side:
- It is our goal to enable higher density on web servers. For a machine running a single application, this might be measured by allowing a greater number of concurrent requests on the machine. For a shared hoster, this might be measured by allowing more active sites on a single machine.
- It is our goal to provide behavior that mimics self-host more than it mimics web-host. We’re trying to eliminate as much magic as possible from the new host.
- It is our goal to make the Helios framework fully out-of-band. The framework should be able to run without requiring installation as long as the target machine meets the minimum system requirements called out below. Developers should be able to acquire bug fixes / feature additions by acquiring updated packages through NuGet and bin-deploying to their servers / hosters.
- It is our goal to reduce the friction of deploying a web application built on the Helios host. It should be just as easy to deploy a Helios-hosted application as it is any typical ASP.NET application.
Getting started
...
...
Conclusion
We’re excited about what this could mean for the future of our platform, especially as more frameworks and components break their strict dependency on System.Web.dll. This new design promises to allow us to ship new functionality fully out-of-band and to avoid surprising developers with unwanted behaviors.
I also want to stress that this is strictly an option. The target audience for this package is a minority of our overall developer audience. The team has no plans to force our general developer audience on to this system.
Finally, there is a supplemental post available with further information available for more advanced developers. That post discusses performance and resource utilization in more detail. It also discusses using the Helios APIs directly without going through OWIN.
Sounds interesting and seems to mesh with hour the BCL team is also iterating faster. Will be keeping an eye on this...
Posts
