50 shades of .NET on AWS

How to host our .NET applications on AWS

  • Always prefer fully managed services to self-managed services when available and applicable
  • For container orchestration, use Amazon Elastic Container Services (ECS) rather than Amazon Elastic Kubernetes (EKS) as it is more opinionated and straightforward to use
  • For container execution, when it matches our hardware requirements, use AWS Fargate, their fully managed serverless compute engine for containers to avoid the burden of operating our own container hosts
  1. Hosting our existing .NET Framework applications with low to no modifications
  2. Hosting .NET Framework microservices that we’ve just extracted from our .NET Framework monoliths and containerized
  3. Hosting containerized .NET 6+ microservices that we’ve ported from .NET Framework
  4. Hosting brand new .NET 6+ microservices
.NET migration use case categorization

Rehost our existing .NET Framework applications

We have hosted our .NET Framework applications on Windows Server virtual machines for years. Our Operations team is highly skilled at operating Windows Server and IIS web server farms. We don’t plan to accelerate the release cadence of our monoliths. We rather prefer to invest into breaking them into microservices. We will concentrate our efforts on our new microservices and setup proper CI/CD pipelines.

Hosting existing .NET Framework applications

Replatform our .NET Framework microservices into containerized microservices

To standardize our packaging and deployment strategy, we have selected container as our corporate standard format for applications we want to modernize. It will allow us to streamline the deployment of our applications across our different environments and speed the process thanks to CI/CD pipelines whatever the programming language used by development teams.

Hosting .NET Framework microservices

Refactor our .NET microservices to .NET 6

As .NET Framework 4.8 is the last version of .NET Framework and will not get any new features, we will port our .NET microservices to .NET 6+ and follow the future of .NET.

Hosting ported to .NET 6+ microservices

Rebuild to brand new .NET 6+ serverless applications

For all our new .NET microservices and applications, we want to favor serverless microservices and applications. We are a developer oriented organization. While we recognize the benefits containers bring to the table, we do believe that managing container definitions and Docker files is not a developer thing.

Hosting brand new .NET 6+ serverless applications
    /// <summary>
/// This method is called for every Lambda invocation.
/// This method takes in an SQS event object and can be used
/// to respond to SQS messages.
/// </summary>
/// <param name="evnt"></param>
/// <param name="context"></param>
/// <returns></returns>
public async Task FunctionHandler(SQSEvent evnt,
ILambdaContext context)
{
foreach(var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
}

Conclusion

AWS, really, offers 50 shades of .NET. Deciding which way to host is the right one for a workload may seem overwhelming at first.
We have built these decision trees to avoid the discussions for each .NET application we want to deploy on AWS. It will enable quick decision in the vast majority of our use cases.

  • We will host .NET Framework monolith applications on AWS Elastic Beanstalk.
  • We will host .NET Framework containerized microservices on AWS Fargate with Amazon ECS managed Windows containers.
  • We will host .NET 6+ containerized microservices on AWS Fargate with Amazon ECS managed Linux containers.
  • We will host new .NET 6+ microservices on AWS Lambda.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store