In this post we're going to discuss different AWS-based modernization strategies for .NET applications. Oftentimes, people assume modernization means completely re-architecting and rewriting an application to leverage new technologies such as microservices, purpose-built databases, serverless functions, etc. And, for some use cases, that is a perfectly valid approach. But most modernization efforts face constraints such as budget, timeline, resource availability, and overall complexity that make a full application overhaul impractical.

But there's good news! Modernization is not an all-or-nothing proposition. You can modernize as much or as little as is feasible and still see appreciable benefits along the way.

Planning Your Journey

Each journey will be different, but two determining factors are ever-present when it comes to modernizing .NET applications: (1) the version of .NET in use; and (2) the underlying operating system on which the application is hosted. The diagram above is very high-level, but should give you a good outline of the options at play.

Note about the diagram: I can assure you I haven't forgotten that applications typically have databases, but I've chosen to address modernizing MSSQL in a separate post. (Yes, I'm going out on a limb and assuming you're using SQL Server.)

.NET Version

This one is a bit obvious, but the first—and most important—determining factor for modernizing a .NET workload is the underlying version of .NET.

.NET Framework

If your application is stuck on .NET Framework you're starting from square one, and you're essentially down to two immediate options:

• Using Windows containers: Lacks some of the benefits seen in the other destinations—particularly around cost.
• Porting the application to .NET 6+: Can be a significant undertaking depending on the complexities and requirements of the existing environment.

Modern .NET

Conversely, if you're already utilizing a modern version of .NET; Congratulations, you're already well down the modernization path! Now—as we'll see in the destinations section below—if you also took the opportunity to host/rehost on Linux you're practically at the finish line.

Operating System

The second major determining factor when deciding your ultimate journey destination is the underlying operating system. Let's be clear, the vast majority of .NET workloads out there run on Windows. I can't find a reliable source, but, if I had to make a guess based on my personal experiences, I'd estimate the ratio to be at least 9:1 in Microsoft's favor.

As outlined in the next section, there are multiple benefits to taking the plunge and rehosting on Linux—but it's not without its risks. Existing workflows will be impacted, finding answers may be more difficult, and developer velocity will almost assuredly take a hit in the short term as personnel adapt to the new ways of working. Personally, I feel the rewards are great enough to warrant moving to Linux when possible—but that's just me. You'll ultimately have to decide what's best for your app, team, and organization.

Destinations

Windows-based Containers

Porting your legacy application to Windows containers is by far the easiest option for Windows-based workloads, but also delivers the least benefits. Both EKS and ECS (including Fargate) support Windows containers so you're covered from an AWS services perspective, but there are a few downsides when compared to Linux containers:

• Higher cost
• Larger containers
• Slower start times
• Less efficient usage of resources
• Lower adoption

This can be a beneficial first step in modernizing .NET Framework applications, but—in my opinion—should not be the end of the journey.

Linux-based Containers

Although containers are now a multi-platform solution, they were initially developed with Linux in mind, and, because of this, Linux containers have a massive head start in terms of adoption, support, and maturity. While Windows containers have made strides in the last few years in terms of usage, Linux containers remain the de-facto standard for enterprise containerization. Unless you are forced to go with Windows for some reason, Linux should be the operating system of choice when containerizing workloads.

Serverless

Serverless is the gold-standard for cloud-native applications, and if we were talking about building a greenfield application, I would tell you that serverless is unequivocally the way to go. After all, the inherent benefits of serverless are well documented and numerous:

• Built-in auto-scaling
• Automatic high-availability
• No server management
• Quick deployments & updates
• Extremely cost-efficient

But when it comes to modernizing an existing application—particularly a large and complicated application—the case for serverless becomes a bit less obvious. Converting an existing application to a serverless architecture can be challenging due to a variety of technical and architectural reasons, and many choose to end their modernization efforts with containerization.

Luckily—for those that choose to forge ahead—AWS Lambda supports container images as a deployment model, meaning the same containers in use today can be used to power your Lambda functions in the future.

How AWS Can Help?

Of course AWS has virtually any need covered from a services perspective, but I wanted to use this space to highlight some lesser-known tools AWS provides specific to .NET modernization:

• AWS App2Container (A2C): Command line tool for migrating and modernizing .NET web applications running in IIS on Windows into container format.
• Porting Assistant for .NET (PA): Analysis tool that scans .NET Framework applications and generates a modern .NET compatibility assessment, helping you port your applications to Linux faster.
• AWS Microservice Extractor for .NET (MSE): Simplifies the process of refactoring older monolithic apps into small code projects to build a microservices-based architecture.
• AWS Toolkit for .NET Refactoring (TR): Visual Studio extension that helps developers refactor legacy .NET applications to cloud-based alternatives on AWS.
• AWS Modernization Calculator for Microsoft Workloads: Interactive tool that helps you estimate the cost of modernizing your Microsoft workloads to a new architecture, using open-source software and cloud-native services on AWS.

Wrapping Up

Hopefully, I've successfully illustrated that when it comes to modernization, there is no one-size-fits-all solution. Each modernization journey will have its own specific sets of external factors, requirements, and challenges that will ultimately determine how best to proceed. For those currently undertaking a .NET modernization effort, good luck! I'd love to hear about your experiences.

Finally, I sincerely hope you enjoyed this post and be on the lookout for my followup article on modernizing SQL Server!