Implications and Considerations for Serverless ASP.NET

This blog post describes implications and considerations for running ASP.NET in a “serverless” environment.

First, I believe that the term serverless is misleading. Without a server, nothing gets served. Without web server software such as the Apache HTTP Server or Internet Information Services (IIS) sitting on some type of hardware device traditionally called a server, nothing gets served. I think what serverless means is that the owner of the application does not manage the server hardware or software, and therefore does not have (complete) control of such systems. The application owner indicates server configuration for a cloud provider, which provisions and manages the servers.

For ASP.NET specifically, this brings one issue immediately to mind: ASP.NET application restarts, which clear memory. Even for trivial ASP.NET applications, restarts take time, especially if the application needs to preload data. With traditional ASP.NET hosting, the client can have some control of application restarts. Even if the load balancer is configured for server affinity/sticky sessions, well-architected applications may use memory for caching, but store persistent data elsewhere and often even cached data elsewhere, which makes that data available to all the servers in the farm. The InProc session storage option that uses memory may have advantages for lightweight development, but persistent session storage mechanisms are appropriate for production. The same applies to any other data used by the application – nothing should depend on anything in memory that did not load at application initialization. Even if the application does not restart, the hardware beneath it could fail at any time.

Because a serverless ASP.NET application could need to start or restart at any moment and potentially much more frequently than with traditional hosting, application initialization and the network connection between local data storage (including cache) and the ASP.NET solution may be of greater concern. Otherwise, if developers follow typical best practices for ASP.NET solutions (generally, avoiding reliance on memory between HTTP calls), it seems that serverless should have minimal or no necessary impact on the application.

With serverless, it may be appropriate to separate what might otherwise have been a single ASP.NET application into multiple applications hosted separately. For example, to reduce server maintenance, a traditional ASP.NET application on a single server may handle requests for pages and also webhook calls from other systems. To (potentially) reduce costs and the chances of issues with webhook logic affecting performance and stability of the web site, a serverless solution architecture might be more likely to separate these two functions, with appropriate hardware sizing for each. Such a solution could simplify deployment of updates to one set of logic without affecting the other.

After I drafted this, I did a quick search and found that Microsoft has published a list of concerns (Serverless architecture considerations – Serverless apps | Microsoft Docs):

• Managing state: I mentioned this in the post.
• Long-running processes: If you cannot architect the solution to avoid long-running processes, you may need to consider architectures other than serverless.
• Startup time: I mentioned this in the post (initialization). The startup performance problem may be worse than just the application initialization time; initialization could require the cloud provider to provision and boot the supporting infrastructure before the application can initialize. Cloud providers offer options to mitigate startup performance issues, but like everything else, at some cost.
• Databases: Not really part of the ASP.NET application or specific to serverless, but certainly some concerns.
• Scaling: Split applications into functions that can scale separately. It is interesting that Microsoft explains serverless as “less server” rather than “no server”.
• Monitoring, tracing, and logging: Apply instrumentation. This is not specific to serverless, but may be more important in serverless environments. I would expect to see debugging in this list, and since I do not, I would hope that there is some way to connect a debugger to a specific instance of the application in the cloud.
• Inter-service dependencies: When services depend on others, use a service discovery mechanism, a messaging service, or another solution. This does not seem specific to serverless.
• Managing failure and providing resiliency: When a call to a service fails, do not simply call that service again until it succeeds, but fail gracefully. This does not seem specific to serverless.
• Versioning and green/blue deployments: To assist in managing change, version functions on which other functions and applications depend. This does not seem specific to serverless.

Maybe it is just me clinging to the known past, maybe I have not uncovered additional valid concerns around serverless, or maybe I just need to accept the issues and get past an initial deployment, but for some reason, for significant applications, I would prefer to manage servers than rely on serverless infrastructure. If I was responsible for real applications, I would move some functions to serverless and evaluate the outcome rather than committing to a complete serverless architecture.

I am sure that I am missing something, but I have been using .NET for almost 20 years and I cannot think of other potential impacts of serverless architecture on ASP.NET. Especially if you have experience with serverless ASP.NET, please comment on this blog post to help me include any issues or concerns that I have missed.