.NET Applications with Linux Containers

Choosing container orchestration

As you re-platform your application, you can select a container orchestrator that is most
suitable for your requirements. 80% of all containers in the cloud run on AWS, and you have a broad set of options to run and manage your containers on AWS. When choosing your container orchestration option, you should start with the question, “How much of the container infrastructure do I want to manage?” The following options are available to you:
• Self-Managed Containers on Amazon Elastic Compute Cloud (Amazon EC2)
— EC2 virtual machines give you full control of your server clusters and provide a broad range of customization options. You can choose Amazon EC2 to run your container orchestration if you need server-level control over the installation,configuration, and management of your container orchestration environment.
• Amazon Elastic Kubernetes Service (Amazon EKS) — Amazon EKS is a managed service that makes it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes control plane or worker nodes.
Amazon EKS provisions and scales the Kubernetes control plane, including the API servers and backend persistence layer, across multiple AWS Availability Zones for high availability and fault tolerance. Amazon EKS integrated with various AWS services such as Elastic Load Balancing, AWS Identity and Access Management
(AWS IAM), Amazon VPC, and AWS CloudTrail to provide scalability and security for your applications.
• Amazon Elastic Container Service (Amazon ECS) — Amazon ECS is a highly scalable, high-performance container management service that supports Docker
containers and enables you to run applications on a managed cluster of Amazon EC2 instances. With simple API calls, you can launch and stop container-enabled applications, query the complete state of your cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes, and IAM roles.You can use Amazon ECS to schedule the placement of containers across your cluster based on your resource needs and availability requirements.Amazon Web Services Modernize .NET Applications with Linux Containers
• AWS Fargate — AWS Fargate is a serverless compute engine for containers that works with both Amazon ECS and Amazon EKS. AWS Fargate removes the need to provision and manage servers and enables you to specify and pay for resources per application. AWS Fargate is the easiest way to get started with containers on AWS. With AWS Fargate, developers don’t have to manage the underlying infrastructure and they can launch and scale their containers easily and manage everything at the container level. This guide uses AWS Fargate for ECS to deploy
containerized .NET Framework applications on AWS.The next section covers some of the tools and libraries that are available to you as you build your .NET applications and DevOps automation on AWS.

Tools and libraries
AWS has many tools available for developers and IT practitioners to build and run container applications and infrastructure. The following table covers some of the primary tools that are useful for the refactoring and replatforming process. You’ll use many of
these tools later on in the Walkthrough section of the guide. For the latest news and releases, visit the .NET on AWS landing page.

AWS container services

There are several cost aspects to consider when running applications on AWS. These include, but are not limited to, storage, data transfer, service usage, compute, and operations. This guide focuses on compute (where the containers run) and operations cost (staffing) of managing the compute resources. To simplify the analysis, it does not include the cost of running a database in the example.
As mentioned, there are four different services that AWS provides to run containerbased applications: Amazon EC2, Amazon EKS, Amazon ECS, and AWS Fargate. To understand the cost implications of running containers on each of these services, this paper reviews an example of a simple application architecture, and compares the cost of running it on each service with an On-Demand pricing model in the us-east-1 Region.As detailed previously, you could choose a different pricing structure such as Spot Instances or Saving Plans, which are supported for the services covered in this guide.The examples in the following sections were generated by the AWS Pricing Calculator.
As the baseline for the comparison, this paper uses an application running on Windows in Amazon EC2, as shown in the following figure:

Self-managed containers on Amazon EC2

Running containers on Amazon EC2 gives you the highest level of control over the underlying compute, but it comes with the highest TCO, because you must manage theentirety of the container’s lifecycle. Additionally, you are responsible for optimally
utilizing the underlying compute, rather than leaving this to the managed container orchestrator.

Amazon EKS

With Amazon EKS, you pay $0.10 per hour for each cluster that you create. You can use a single Amazon EKS cluster to run multiple applications by taking advantage of Kubernetes namespaces and IAM security policies. You can run Amazon EKS on AWS using either Amazon EC2 or AWS Fargate, and on-premises using AWS Outposts or
Amazon EKS Anywhere

If you are using Amazon EC2 (including with Amazon EKS-managed node groups), you pay for AWS resources (such as EC2 instances or EBS volumes) you create to run your Kubernetes worker nodes. You pay only for what you use, as you use it; there are no minimum fees and no upfront commitments.
The calculations in this guide use Amazon EC2 for compute. For more details on Amazon EKS pricing, see the Amazon EKS pricing page.

Amazon ECS

With Amazon ECS, there is no additional charge for the cluster management. You can run Amazon ECS on AWS using either Amazon EC2 or AWS Fargate, and on-premises using AWS Outposts or Amazon ECS Anywhere. Again, you only pay for what you use, as you use it.

For the calculations in this guide, we used EC2 for compute, and for more details on ECS pricing reference the Amazon ECS pricing page

AWS Fargate

AWS Fargate can be used to run containers on Amazon ECS and Amazon EKS, removing the operational cost of managing the underlying infrastructure yourself. Pricing is calculated based on the vCPU and memory resources used from the time you start to download your container image until the Amazon ECS Task or Amazon EKS Pod ends,
rounded up to the nearest second.

For simplicity, this guide assumes that AWS Fargate will run all the time (730 hours per month), but ideally you benefit more from AWS Fargate when cluster utilization falls under certain thresholds. Windows containers are not supported to run on AWS Fargate at this time. Therefore this paper estimates only the cost of running Linux containers. See the AWS Fargate pricing page for more information.

Architecture overview

It’s common for enterprise applications built in the last decade to follow a layered N-Tier architectural approach. The unctionally for different aspects of the application are logically separated, yet bundled together as interdependent code modules.
There are multiple advantages of an N-Tier architecture. They’re easy to develop, more feasible to test if the application size is small, and can scale vertically. However, as more functionality is added and the code base grows, the applications become
cumbersome to manage, change, and scale. State-dependent applications are particularly difficult to scale horizontally, and the compute capacity must be provisioned to consider the peak load.

Many customers start their cloud journey with a lift-and-shift approach, running their NTier .NET Framework applications on EC2 without any code changes. It’s common for these deployments to have more than one EC2 Windows instance with an Application Load Balancer (ALB), routing the user requests to one of the EC2 instances. A stateful application can have session affinity (sticky sessions) enabled at the ALB level to create an affinity between a client and a specific EC2 instance.
Along with the ALB, developers can use AWS Auto Scaling to monitor an application and automatically adjust capacity to maintain steady, predictable performance at the lowest possible cost. Amazon RDS for SQL Server is a managed database service that
frees you up to focus on application development by managing time-consuming database administration tasks, including provisioning, backups, software patching,monitoring, and hardware scaling.
This guide refactors this traditional N-Tier .NET Framework application to run on Amazon ECS with AWS Fargate. As mentioned in the previous sections, running containers on Amazon EC2 and Amazon EKS is also an option, but using Amazon ECS and AWS Fargate is a simple yet powerful place to start if you and your teams are new
to containers.
Fargate integrates natively with AWS services such as Application Load Balancer and AWS Auto Scaling, enabling developers to start with the minimum amount of compute to meet user requirements and scale dynamically as the incoming traffic increases. The high-level architecture for the containerized version of this application follows, and is the target of the transformation detailed in this guide. In the following figure, the one vCPU,
two GB blocks represent the AWS Fargate tasks where the application containers are running.

Additional benefits of moving to containers are realized when teams also implement automation and DevOps. A cloud-optimized, containerized application allows you toquickly and frequently deliver consistent applications to your users. A common
development pipeline for continuous deployment with AWS follows.

Reference
Original paper