Migrating and modernizing Windows Communication Foundation (WCF) workloads onto Amazon container services

{"value":"### **Introduction**\nWindows Communication Foundation (WCF) is a framework created by Microsoft in 2008 for building service-oriented architecture (SOA) applications. It provides a set of libraries for building web services, using different network protocols to send and receive data between service endpoints.\n\nWith the introduction of .NET Core in 2016 and the emergence of microservices, our customers have gradually adopted other highly interoperable, cross-platform, language-agnostic, and high-performance solutions for building web services, such as REST APIs on ASP.NET Web API and Google Remote Procedure Call (gRPC). However, it is common that many organizations still run their legacy WCF-based applications on Windows platforms. In addition, many of our customers adopt container strategies and wish to containerize their legacy WCF workloads to run on AWS container services so that they can fully realize the benefits of containerization—increased operational efficiency, reduced infrastructure cost, increased development and deployment agility with standardized builds, and deployment processes across their organization.\n\nThis blog post discusses the background of WCF, .NET, and a few other alternatives to WCF in .NET. It also recommends different solutions and strategies for migrating and modernizing WCF workloads onto AWS container services.\n\n### **Background**\nWCF was introduced in .NET Framework 3.5, providing a set of libraries for building SOA web services. WCF workloads follow client-server architecture using two primary network communication protocols: HTTP and NetTCP, a high-performance, TCP-based network protocol introduced specifically in WCF. NetTCP-based WCF workloads require that both the client and server are implemented in .NET Framework. In 2016, WCF was removed from Microsoft’s strategic, cross-platform successor of .NET Framework, .NET Core, which is now called .NET. In this blog post, we will use .NET Core and .NET interchangeably.\n\n#### **REST APIs and gRPC**\nSince WCF is not supported in .NET, our customers are encouraged to use [ASP.NET](http://asp.net/) Web API (REST APIs) or gRPC to build new web services in .NET. gRPC is cross platform, lightweight, highly performant for building web services, and officially supported in .NET. In some cases, gRPC-based applications provide even higher performance, with the flexibility of being language agnostic, when compared to NetTCP-based WCF workloads.\n\n#### **Core WCF**\nIn 2019, .NET Foundation sponsored an open-source project called [Core WCF](https://github.com/CoreWCF/CoreWCF), which was later jointly supported by AWS, to provide a port of WCF to .NET. To be able to use WCF in .NET, you need to first port your existing .NET Framework applications to .NET and replace the WCF libraries with the comparable libraries available in Core WCF. At the time of writing this blog post, certain features from WCF might not be supported in Core WCF. Hence, we recommend that you check out the [official announcements](https://github.com/CoreWCF/announcements) from the Core WCF team.\n\n#### **Microservices and containers**\nIn recent years, we have seen a tremendous shift in adopting microservices architecture. In addition, our customers usually use container services to help with deploying, running, and managing their microservices. Many of our customers would also like to run or modernize their legacy workloads to be able to run on a container service.\n\nWith WCF in particular, we are often asked by our customers for guidance in modernizing their WCF workloads, specifically, how to run their WCF workloads on AWS container services. With .NET, Core WCF, other technologies such as REST APIs on ASP.NET Web API, and gRPC, there are plenty of options to migrate or modernize their WCF workloads onto a container service. You can replatform or refactor your workloads to be hosted on AWS by utilizing one or more of the strategies mentioned in the [6 strategies for Migrating Applications to the Cloud](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/) blog post. This is described in the following sections.\n\n### **Replatforming**\nYou can Dockerize your WCF workloads using one of the Microsoft Windows base images and deploy the workloads to one of the AWS container services. Compared to the refactoring approach, this approach generally involves fewer changes to the application and, hence, decreased time to market. It also maintains compatibility, so it reduces any potential impacts to the existing workloads. However, some changes might be required to ensure all current features are working as expected in a container environment. You need to also spend efforts in preparing the container. This approach is most suitable for the following workloads:\n\n- Mission-critical workloads where stability and minimal modification to the application are desired\n- NetTCP workloads where refactoring and modernizing to .NET using [gRPC](https://grpc.io/) or [Core WCF](https://github.com/CoreWCF/CoreWCF) involves a higher degree of complexity and effort in refactoring the WCF backend and, likely, its clients\n- Workloads that cannot change API contract due to restrictions from client’s implementation\n\n\nWe advise you to conduct thorough application code assessments that might not work or might require changes to work in Windows containers, such as reading and writing permissions to the Windows Registry; local file storage; related domain-joined security features, such as Windows authentication; in-memory local session data; and so on. Extra efforts might also be required, such as installing and configuring the tools and software that are currently required in the virtual machines (VMs) to the containers. These changes and extra efforts can vary depending on the current setup. It’s important to take them into account to estimate the work required for this approach.\n\nYou can also use [AWS App2Container](https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html) to reduce the complexity and manual efforts in containerizing your IIS-hosted WCF workloads. For NetTCP workloads, you need to use a Network Load Balancer (NLB). While with HTTP workloads, both an Application Load Balancer and a Network Load Balancer are suitable. The following [base images](https://hub.docker.com/_/microsoft-windows-base-os-images) can be used to Dockerize the workloads:\n\n- Windows Server Core\n- Windows\n\n\nThe containerized workloads are supported on the following services:\n\n- Amazon Elastic Container Service (Amazon ECS) with Amazon Elastic Compute Cloud (Amazon EC2)\n- Amazon ECS with AWS Fargate\n- Amazon Elastic Kubernetes Service (Amazon EKS)\n\n\n**Note:** Currently Amazon EKS with Fargate and AWS Elastic Beanstalk does not support Windows containers.\n\nCustomers adopting this approach should also consider the containers’ size in their architectural and operational considerations. Sizeable Windows container base images can cause prolonged startup time and could impact the time taken in scaling events, such as scaling out. Building Windows-based containers requires using Docker on Windows, which is equally important; thus, having a continuous integration and continuous delivery (CI/CD) system that is capable of building Windows containers is required.\n\n### **Refactoring**\nIn this approach, we recommend refactoring the WCF workloads to cross-platform .NET workloads. Refactoring is most suitable for you if you have a strategy and are willing to spend extra effort to refactor and containerize the workloads to .NET running on Linux or Windows containers. By refactoring to .NET, you can enjoy a wide range of benefits:\n\n- **Long-term support—**.NET is open source and strategically supported by Microsoft. Both REST APIs on ASP.NET Web AP and gRPC are proven, widely adopted technologies. Core WCF is also backed by .NET Foundation and AWS.\n- **Increased resource efficiency and performance—**.NET workloads work across platforms and can run on small-footprint, highly performant, and widely supported Linux and Windows (Nano Server) containers. Unlike Windows Server Core and Windows base images, Nano Server base image is significantly smaller in size. You can now run more containers on the same provisioned compute resource.\nWorkloads can also respond to scaling events quicker compared to running on full Windows base images, increasing agility as well as operational resiliency.\n- **Cost savings—** Costs are reduced thanks to improved resource usage efficiency, reduced operational overheads, license-free Linux containers, and shared platform costs. At scale, running on license-free Linux containers can bring savings by avoiding the license-included cost on Amazon EC2 Windows instances.\n- **Wider range of options for choosing a container service—** There are more options because the workloads can run on either Linux or Windows containers.\n\n\nOur customers generally have two options in this approach:\n\n- **Move away from WCF—** Port the applications to .NET and modernize the applications to ASP.NET Web API or gRPC technologies. Under this option, customers are able to benefit from these highly interoperable and cross-platform technologies. This option involves refactoring WCF workloads with the HTTP protocol to ASP.NET Web API. In addition, customers can also port their NetTCP WCF applications to gRPC on .NET. gRPC provides comparable performance and, in most cases, better performance, with NetTCP. It is required that customers spend efforts in both porting the current applications to .NET and rewriting the application to adopt gRPC or ASP.NET Web API. It also requires contract changes and breaking compatibility, hence involving additional efforts in changing the client’s implementation due to the new API contracts.\n- **Stay with WCF—** Port the applications to .NET but still maintain the WCF API contracts by using Core WCF. This option is ideal for customers who are willing to adopt .NET but not willing to spend further efforts refactoring and making significant changes to the applications. It not only provides the benefits of running on .NET but also reduces the potential impacts to the current workloads by not breaking or minimally breaking changes to the API contracts. However, it is important to note that Core WCF is still under active development and currently does not support all the bindings, transports, and security models currently available in WCF.\n\n\nYou can also use [Porting Assistant](https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/) for .NET to reduce the complexity and manual effort in porting your WCF workloads to .NET. Recently, .NET Porting Assistant has added support for porting WCF workloads to Core WCF.\n\nThe following table summarizes the high-level steps required for both replatforming and refactoring.\n\n\n\n\n\nThe modernized workloads can be hosted in both Windows and Linux containers on the following platforms:\n\n- Elastic Beanstalk (Linux containers)\n- Amazon ECS with Amazon EC2\n- Amazon ECS with Fargate\n- Amazon EKS\n- Amazon EKS with Fargate (Linux containers)\n- AWS App Runner (Linux containers)\n\n\n**Note:** Currently Amazon EKS with Fargate and Elastic Beanstalk does not support Windows containers.\n\n### **Examples**\nIn the following examples, we will replatform and refactor the server-side application from a WCF-based system to Amazon ECS with Fargate. The system follows the traditional client-server architecture, and both server and clients use WCF on .NET Framework 4.8.\n\n\n\n##### **Prerequisites**\nThe examples require the following tools:\n\n- AWS Command Line Interface (AWS CLI) with default Region set\n- Docker Desktop\n- .NET Framework 4.8 SDK and MSBuild\n- .NET 6\n- [AWS Copilot CLI](https://aws.github.io/copilot-cli/) (which you should ensure is widely available through the PATH system variable)\n- jq\n\n\n##### **Replatforming**\nIn this example, we containerize the WCF server-side application into an Amazon ECS cluster and host it using Fargate. The following is the new architecture.\n\n\n\n##### **Dockerfile**\nHere is the Dockerfile for this solution with the following notes:\n\nWindows Server Core 2019 LTSC is selected as it is currently supported by Amazon ECS with Fargate.\nTwo ports are exposed on the container—```80```\n (HTTP) and ```808``` (NetTCP).\n\n\n\n##### **Deploy ECS cluster**\nSince this is a Windows base image, switching to Windows containers mode on Docker Desktop is required. Create a new Amazon ECS cluster using the following commands:\n\nPowerShell\n```\ngit clone https://github.com/aws-samples/containerization-options-for-wcf \ncd containerization-options-for-wcf/src/Replatforming\nmkdir copilot/replatforming\n@'\nname: replatforming\ntype: Load Balanced Web Service\n\nhttp:\n path: \"/\"\n healthcheck:\n path: \"/CalculatorService\"\n success_codes: \"200\"\n healthy_threshold: 3\n unhealthy_threshold: 5\n interval: 15s\n timeout: 10s\n grace_period: 45s\n\nnlb:\n port: 808/tcp\n target_port: 808\n\nimage:\n build:\n dockerfile: Dockerfile\n port: 80\n\ncpu: 4096\nmemory: 8192\ncount: 2\nplatform: windows/x86_64\nenvironments:\n test:\n count: 2\n deployment:\n rolling: \"recreate\"\n'@ | Out-File ./copilot/replatforming/manifest.yml\ncopilot app init wcfreplatforming\ncopilot init --name replatforming --type \"Load Balanced Web Service\" --deploy\n```\n\nOnce the stack is created, let’s inspect the Docker container size:\n\nPowerShell\n```\ndocker images --format \"{{.Repository}}: {{.Size}}\" \"*/wcfreplatforming/replatforming:latest\"\n```\n\n\nThe size should be around 8.25 GB:\n\nPowerShell\n```\n444455556666.dkr.ecr.ap-southeast-2.amazonaws.com/wcfreplatforming/replatforming: 8.25GB\n```\n\n\n##### **Testing**\nBuild the client application:\n\nPowerShell\n```\n$LB_HTTP_DNS = (copilot svc show --app wcfreplatforming --name replatforming --json | jq -r .routes[0].url).Split(\" \")[0]\n$LB_NETTCP_DNS = (copilot svc show --app wcfreplatforming --name replatforming --json | jq -r .routes[0].url).Split(\" \")[2]\ncd ../CurrentWorkload/Client\nMsBuild.exe Client/Client.csproj /property:Configuration=Release\n```\n\nTest the HTTP protocol:\n\nPowerShell\n```\n.\\Client\\bin\\Release\\Client.exe $LB_HTTP_DNS\n```\n\n\n\nTest the NetTCP protocol:\n\nPowerShell\n```\n.\\Client\\bin\\Release\\Client.exe $LB_NETTCP_DNS\n```\n\n\n\n##### **Clean up**\nUse the following command to clean up the resource:\n\nPowerShell\n```\ncd ..\\..\\Replatforming\ncopilot app delete\n```\n\nThere are a few implications due to large container size:\n\n- When using Amazon ECS or Amazon EKS with Amazon EC2, ensure that underlying storage has enough free space to spin up new container instances as required.\n- Ensure the container image repository is closer to the compute (Amazon EC2 instance or Fargate), ideally using Amazon Elastic Container Registry (Amazon ECR) in the same Region to reduce download time. This in turn reduces the startup time and data transfer charges. You can [implement cache strategy](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/) to avoid expensive operations on the disk and shorten the container startup time.\n- Containers startup time must be taken into consideration from an architecture and operation point of view. With a spiky workload, it is important to ensure the number of running containers is able to handle the spiky traffic. You should also consider using time-based auto scaling to handle predictable traffic.\n\n\n#### **Refactoring using Core WCF**\nIn this example, we will modernize the server-side application to .NET 6 using Porting Assistant for .NET and Core WCF. Thanks to Core WCF, all the API contracts remain the same; thus, the client application will not be changed. To find out about using Porting Assistant for .NET, please refer to the blog post on [Modernizing legacy WCF applications to Core WCF using Porting Assistant for .NET](https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/). The following is the architecture for this example.\n\n\n\n##### **Dockerfile**\nHere is the Dockerfile for the modernized solution with the following notes:\n\nWe use Microsoft’s standard images; however, customers can use other base images with .NET 6 SDK and runtime installed.\nTwo ports are exposed on the container: ```80``` (HTTP) and ```808``` (NetTCP).\nThese base images are Linux-based; hence, switching to Linux containers is required on Docker Desktop.\n\n\n\n##### **Deploy ECS cluster**\nCreate a new ECS cluster using the following commands:\n\nPowerShell\n```\ngit clone https://github.com/aws-samples/containerization-options-for-wcf \ncd containerization-options-for-wcf/src/Refactoring\nmkdir copilot/refactoring\n@'\nname: refactoring\ntype: Load Balanced Web Service\n\nhttp:\n path: \"/\"\n healthcheck:\n path: \"/health-check\"\n success_codes: \"200\"\n healthy_threshold: 3\n unhealthy_threshold: 5\n interval: 15s\n timeout: 10s\n grace_period: 45s\n\nnlb:\n port: 808/tcp\n target_port: 808\n\nimage:\n build:\n dockerfile: Dockerfile\n port: 80\n\ncpu: 4096\nmemory: 8192\ncount: 2\nenvironments:\n test:\n count: 2\n deployment:\n rolling: \"recreate\"\n'@ | Out-File ./copilot/refactoring/manifest.yml\ncopilot app init wcfrefactoring\ncopilot init --name refactoring --type \"Load Balanced Web Service\" --deploy\n```\n\nInspect the size of the container image:\n\nPowerShell\n```\ndocker images --format \"{{.Repository}}: {{.Size}}\" \"*/wcfrefactoring/refactoring:latest\"\n```\n\nIt is about 117 MB compared to 8.2 GB in the previous example.\n\nPowerShell\n```\n444455556666.dkr.ecr.ap-southeast-2.amazonaws.com/wcfrefactoring/refactoring: 117MB\n```\n\n##### **Testing**\nBuild the client application:\n\nPowerShell\n```\n$LB_HTTP_DNS = (copilot svc show --app wcfrefactoring --name refactoring --json | jq -r .routes[0].url).Split(\" \")[0]\n$LB_NETTCP_DNS = (copilot svc show --app wcfrefactoring --name refactoring --json | jq -r .routes[0].url).Split(\" \")[2]\ncd ../CurrentWorkload/Client\nMsBuild.exe Client/Client.csproj /property:Configuration=Release\n```\n\nTest the HTTP protocol:\n\nPowerShell\n```\n.\\Client\\bin\\Release\\Client.exe $LB_HTTP_DNS\n```\n\n\n\nTest the NetTCP protocol:\n\nPowerShell\n```\n.\\Client\\bin\\Release\\Client.exe $LB_NETTCP_DNS\n```\n\n\n\nIn this example, we deployed a modernized WCF workload to Amazon ECS with Fargate. The workload is license-free, is significantly smaller in size, has a quicker startup time, and is highly optimized, hence requiring smaller compute and storage requirements while offering better overall performance.\n\n##### **Clean up**\nUse the following command to clean up the resource:\n\nPowerShell\n```\ncd ..\\..\\Refactoring\ncopilot app delete\n```\n\n### **Conclusion**\nIn this blog, we walk you through different options for migrating and modernizing WCF workloads onto one of the AWS container services. Replatforming is more suitable for workloads that require minimal application changes and maintain backward compatibility. Our customers can also benefit from refactoring the workloads onto a modern .NET using ASP.NET Web API, gRPC, or Core WCF. The refactored workloads work across platforms and can be run on both Linux and Windows containers, hence enabling customers to fully realize the benefits of containerization.\n\nCustomers are also encouraged to check out the following resources:\n\n- [AWS App2Container](https://aws.amazon.com/blogs/modernizing-with-aws/aws-app2container-support-for-windows-on-aws-fargate/)\n- [.NET Porting Assistant](https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/)\n- [Core WCF samples](https://github.com/CoreWCF/samples)\n- [Core WCF announcements](https://github.com/CoreWCF/announcements)\n- [WCF official documentation](https://docs.microsoft.com/en-us/dotnet/framework/wcf/)\n\n\n\n**Minh Tuan Huynh**\n\nBased in Melbourne, Australia, Tuan is a Cloud Application Architect at AWS focusing on Applications Migration and Modernisation. He enjoys helping customers to achieve their business outcome through transformation & modernisation. Outside of works, he is a big fan of soccer, loves road trips, travelling with family members and friends, and passionate in making his house more energy-efficient and smart.\n\n\n\n**Haofei Feng**\n\nHaofei is a Senior Cloud Architect at AWS with 16+ years experiences in Containers, DevOps and IT Infrastructure. He enjoys helping customers with their cloud journey. He is also keen to assist his customers to design and build scalable, secure and optimized container workloads on AWS. In his spare time, he spent time with his family and his lovely Border Collie. Haofei is based in Sydney, Australia.","render":"<h3><a id=\"Introduction_0\"></a><strong>Introduction</strong></h3>\n<p>Windows Communication Foundation (WCF) is a framework created by Microsoft in 2008 for building service-oriented architecture (SOA) applications. It provides a set of libraries for building web services, using different network protocols to send and receive data between service endpoints.</p>\n<p>With the introduction of .NET Core in 2016 and the emergence of microservices, our customers have gradually adopted other highly interoperable, cross-platform, language-agnostic, and high-performance solutions for building web services, such as REST APIs on ASP.NET Web API and Google Remote Procedure Call (gRPC). However, it is common that many organizations still run their legacy WCF-based applications on Windows platforms. In addition, many of our customers adopt container strategies and wish to containerize their legacy WCF workloads to run on AWS container services so that they can fully realize the benefits of containerization—increased operational efficiency, reduced infrastructure cost, increased development and deployment agility with standardized builds, and deployment processes across their organization.</p>\n<p>This blog post discusses the background of WCF, .NET, and a few other alternatives to WCF in .NET. It also recommends different solutions and strategies for migrating and modernizing WCF workloads onto AWS container services.</p>\n<h3><a id=\"Background_7\"></a><strong>Background</strong></h3>\n<p>WCF was introduced in .NET Framework 3.5, providing a set of libraries for building SOA web services. WCF workloads follow client-server architecture using two primary network communication protocols: HTTP and NetTCP, a high-performance, TCP-based network protocol introduced specifically in WCF. NetTCP-based WCF workloads require that both the client and server are implemented in .NET Framework. In 2016, WCF was removed from Microsoft’s strategic, cross-platform successor of .NET Framework, .NET Core, which is now called .NET. In this blog post, we will use .NET Core and .NET interchangeably.</p>\n<h4><a id=\"REST_APIs_and_gRPC_10\"></a><strong>REST APIs and gRPC</strong></h4>\n<p>Since WCF is not supported in .NET, our customers are encouraged to use <a href=\"http://asp.net/\" target=\"_blank\">ASP.NET</a> Web API (REST APIs) or gRPC to build new web services in .NET. gRPC is cross platform, lightweight, highly performant for building web services, and officially supported in .NET. In some cases, gRPC-based applications provide even higher performance, with the flexibility of being language agnostic, when compared to NetTCP-based WCF workloads.</p>\n<h4><a id=\"Core_WCF_13\"></a><strong>Core WCF</strong></h4>\n<p>In 2019, .NET Foundation sponsored an open-source project called <a href=\"https://github.com/CoreWCF/CoreWCF\" target=\"_blank\">Core WCF</a>, which was later jointly supported by AWS, to provide a port of WCF to .NET. To be able to use WCF in .NET, you need to first port your existing .NET Framework applications to .NET and replace the WCF libraries with the comparable libraries available in Core WCF. At the time of writing this blog post, certain features from WCF might not be supported in Core WCF. Hence, we recommend that you check out the <a href=\"https://github.com/CoreWCF/announcements\" target=\"_blank\">official announcements</a> from the Core WCF team.</p>\n<h4><a id=\"Microservices_and_containers_16\"></a><strong>Microservices and containers</strong></h4>\n<p>In recent years, we have seen a tremendous shift in adopting microservices architecture. In addition, our customers usually use container services to help with deploying, running, and managing their microservices. Many of our customers would also like to run or modernize their legacy workloads to be able to run on a container service.</p>\n<p>With WCF in particular, we are often asked by our customers for guidance in modernizing their WCF workloads, specifically, how to run their WCF workloads on AWS container services. With .NET, Core WCF, other technologies such as REST APIs on ASP.NET Web API, and gRPC, there are plenty of options to migrate or modernize their WCF workloads onto a container service. You can replatform or refactor your workloads to be hosted on AWS by utilizing one or more of the strategies mentioned in the <a href=\"https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/\" target=\"_blank\">6 strategies for Migrating Applications to the Cloud</a> blog post. This is described in the following sections.</p>\n<h3><a id=\"Replatforming_21\"></a><strong>Replatforming</strong></h3>\n<p>You can Dockerize your WCF workloads using one of the Microsoft Windows base images and deploy the workloads to one of the AWS container services. Compared to the refactoring approach, this approach generally involves fewer changes to the application and, hence, decreased time to market. It also maintains compatibility, so it reduces any potential impacts to the existing workloads. However, some changes might be required to ensure all current features are working as expected in a container environment. You need to also spend efforts in preparing the container. This approach is most suitable for the following workloads:</p>\n<ul>\n<li>Mission-critical workloads where stability and minimal modification to the application are desired</li>\n<li>NetTCP workloads where refactoring and modernizing to .NET using <a href=\"https://grpc.io/\" target=\"_blank\">gRPC</a> or <a href=\"https://github.com/CoreWCF/CoreWCF\" target=\"_blank\">Core WCF</a> involves a higher degree of complexity and effort in refactoring the WCF backend and, likely, its clients</li>\n<li>Workloads that cannot change API contract due to restrictions from client’s implementation</li>\n</ul>\n<p>We advise you to conduct thorough application code assessments that might not work or might require changes to work in Windows containers, such as reading and writing permissions to the Windows Registry; local file storage; related domain-joined security features, such as Windows authentication; in-memory local session data; and so on. Extra efforts might also be required, such as installing and configuring the tools and software that are currently required in the virtual machines (VMs) to the containers. These changes and extra efforts can vary depending on the current setup. It’s important to take them into account to estimate the work required for this approach.</p>\n<p>You can also use <a href=\"https://docs.aws.amazon.com/app2container/latest/UserGuide/what-is-a2c.html\" target=\"_blank\">AWS App2Container</a> to reduce the complexity and manual efforts in containerizing your IIS-hosted WCF workloads. For NetTCP workloads, you need to use a Network Load Balancer (NLB). While with HTTP workloads, both an Application Load Balancer and a Network Load Balancer are suitable. The following <a href=\"https://hub.docker.com/_/microsoft-windows-base-os-images\" target=\"_blank\">base images</a> can be used to Dockerize the workloads:</p>\n<ul>\n<li>Windows Server Core</li>\n<li>Windows</li>\n</ul>\n<p>The containerized workloads are supported on the following services:</p>\n<ul>\n<li>Amazon Elastic Container Service (Amazon ECS) with Amazon Elastic Compute Cloud (Amazon EC2)</li>\n<li>Amazon ECS with AWS Fargate</li>\n<li>Amazon Elastic Kubernetes Service (Amazon EKS)</li>\n</ul>\n<p><strong>Note:</strong> Currently Amazon EKS with Fargate and AWS Elastic Beanstalk does not support Windows containers.</p>\n<p>Customers adopting this approach should also consider the containers’ size in their architectural and operational considerations. Sizeable Windows container base images can cause prolonged startup time and could impact the time taken in scaling events, such as scaling out. Building Windows-based containers requires using Docker on Windows, which is equally important; thus, having a continuous integration and continuous delivery (CI/CD) system that is capable of building Windows containers is required.</p>\n<h3><a id=\"Refactoring_48\"></a><strong>Refactoring</strong></h3>\n<p>In this approach, we recommend refactoring the WCF workloads to cross-platform .NET workloads. Refactoring is most suitable for you if you have a strategy and are willing to spend extra effort to refactor and containerize the workloads to .NET running on Linux or Windows containers. By refactoring to .NET, you can enjoy a wide range of benefits:</p>\n<ul>\n<li><strong>Long-term support—</strong>.NET is open source and strategically supported by Microsoft. Both REST APIs on ASP.NET Web AP and gRPC are proven, widely adopted technologies. Core WCF is also backed by .NET Foundation and AWS.</li>\n<li><strong>Increased resource efficiency and performance—</strong>.NET workloads work across platforms and can run on small-footprint, highly performant, and widely supported Linux and Windows (Nano Server) containers. Unlike Windows Server Core and Windows base images, Nano Server base image is significantly smaller in size. You can now run more containers on the same provisioned compute resource.<br />\nWorkloads can also respond to scaling events quicker compared to running on full Windows base images, increasing agility as well as operational resiliency.</li>\n<li><strong>Cost savings—</strong> Costs are reduced thanks to improved resource usage efficiency, reduced operational overheads, license-free Linux containers, and shared platform costs. At scale, running on license-free Linux containers can bring savings by avoiding the license-included cost on Amazon EC2 Windows instances.</li>\n<li><strong>Wider range of options for choosing a container service—</strong> There are more options because the workloads can run on either Linux or Windows containers.</li>\n</ul>\n<p>Our customers generally have two options in this approach:</p>\n<ul>\n<li><strong>Move away from WCF—</strong> Port the applications to .NET and modernize the applications to ASP.NET Web API or gRPC technologies. Under this option, customers are able to benefit from these highly interoperable and cross-platform technologies. This option involves refactoring WCF workloads with the HTTP protocol to ASP.NET Web API. In addition, customers can also port their NetTCP WCF applications to gRPC on .NET. gRPC provides comparable performance and, in most cases, better performance, with NetTCP. It is required that customers spend efforts in both porting the current applications to .NET and rewriting the application to adopt gRPC or ASP.NET Web API. It also requires contract changes and breaking compatibility, hence involving additional efforts in changing the client’s implementation due to the new API contracts.</li>\n<li><strong>Stay with WCF—</strong> Port the applications to .NET but still maintain the WCF API contracts by using Core WCF. This option is ideal for customers who are willing to adopt .NET but not willing to spend further efforts refactoring and making significant changes to the applications. It not only provides the benefits of running on .NET but also reduces the potential impacts to the current workloads by not breaking or minimally breaking changes to the API contracts. However, it is important to note that Core WCF is still under active development and currently does not support all the bindings, transports, and security models currently available in WCF.</li>\n</ul>\n<p>You can also use <a href=\"https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/\" target=\"_blank\">Porting Assistant</a> for .NET to reduce the complexity and manual effort in porting your WCF workloads to .NET. Recently, .NET Porting Assistant has added support for porting WCF workloads to Core WCF.</p>\n<p>The following table summarizes the high-level steps required for both replatforming and refactoring.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/e75f462887b94f0396b061778c9f71d1_image.png\" alt=\"image.png\" /></p>\n<p>The modernized workloads can be hosted in both Windows and Linux containers on the following platforms:</p>\n<ul>\n<li>Elastic Beanstalk (Linux containers)</li>\n<li>Amazon ECS with Amazon EC2</li>\n<li>Amazon ECS with Fargate</li>\n<li>Amazon EKS</li>\n<li>Amazon EKS with Fargate (Linux containers)</li>\n<li>AWS App Runner (Linux containers)</li>\n</ul>\n<p><strong>Note:</strong> Currently Amazon EKS with Fargate and Elastic Beanstalk does not support Windows containers.</p>\n<h3><a id=\"Examples_84\"></a><strong>Examples</strong></h3>\n<p>In the following examples, we will replatform and refactor the server-side application from a WCF-based system to Amazon ECS with Fargate. The system follows the traditional client-server architecture, and both server and clients use WCF on .NET Framework 4.8.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/44aa8094fad84e77843c698304d57814_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Prerequisites_89\"></a><strong>Prerequisites</strong></h5>\n<p>The examples require the following tools:</p>\n<ul>\n<li>AWS Command Line Interface (AWS CLI) with default Region set</li>\n<li>Docker Desktop</li>\n<li>.NET Framework 4.8 SDK and MSBuild</li>\n<li>.NET 6</li>\n<li><a href=\"https://aws.github.io/copilot-cli/\" target=\"_blank\">AWS Copilot CLI</a> (which you should ensure is widely available through the PATH system variable)</li>\n<li>jq</li>\n</ul>\n<h5><a id=\"Replatforming_100\"></a><strong>Replatforming</strong></h5>\n<p>In this example, we containerize the WCF server-side application into an Amazon ECS cluster and host it using Fargate. The following is the new architecture.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/47ba820fec6043f2845bf151dfca297f_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Dockerfile_105\"></a><strong>Dockerfile</strong></h5>\n<p>Here is the Dockerfile for this solution with the following notes:</p>\n<p>Windows Server Core 2019 LTSC is selected as it is currently supported by Amazon ECS with Fargate.<br />\nTwo ports are exposed on the container—<code>80</code><br />\n(HTTP) and <code>808</code> (NetTCP).</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/cc7e51b72630457db7d5a227d6ce8d97_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Deploy_ECS_cluster_114\"></a><strong>Deploy ECS cluster</strong></h5>\n<p>Since this is a Windows base image, switching to Windows containers mode on Docker Desktop is required. Create a new Amazon ECS cluster using the following commands:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">git clone https://github.com/aws-samples/containerization-options-for-wcf \ncd containerization-options-for-wcf/src/Replatforming\nmkdir copilot/replatforming\n@'\nname: replatforming\ntype: Load Balanced Web Service\n\nhttp:\n path: &quot;/&quot;\n healthcheck:\n path: &quot;/CalculatorService&quot;\n success_codes: &quot;200&quot;\n healthy_threshold: 3\n unhealthy_threshold: 5\n interval: 15s\n timeout: 10s\n grace_period: 45s\n\nnlb:\n port: 808/tcp\n target_port: 808\n\nimage:\n build:\n dockerfile: Dockerfile\n port: 80\n\ncpu: 4096\nmemory: 8192\ncount: 2\nplatform: windows/x86_64\nenvironments:\n test:\n count: 2\n deployment:\n rolling: &quot;recreate&quot;\n'@ | Out-File ./copilot/replatforming/manifest.yml\ncopilot app init wcfreplatforming\ncopilot init --name replatforming --type &quot;Load Balanced Web Service&quot; --deploy\n</code></pre>\n<p>Once the stack is created, let’s inspect the Docker container size:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">docker images --format &quot;{{.Repository}}: {{.Size}}&quot; &quot;*/wcfreplatforming/replatforming:latest&quot;\n</code></pre>\n<p>The size should be around 8.25 GB:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">444455556666.dkr.ecr.ap-southeast-2.amazonaws.com/wcfreplatforming/replatforming: 8.25GB\n</code></pre>\n<h5><a id=\"Testing_176\"></a><strong>Testing</strong></h5>\n<p>Build the client application:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">$LB_HTTP_DNS = (copilot svc show --app wcfreplatforming --name replatforming --json | jq -r .routes[0].url).Split(&quot; &quot;)[0]\n$LB_NETTCP_DNS = (copilot svc show --app wcfreplatforming --name replatforming --json | jq -r .routes[0].url).Split(&quot; &quot;)[2]\ncd ../CurrentWorkload/Client\nMsBuild.exe Client/Client.csproj /property:Configuration=Release\n</code></pre>\n<p>Test the HTTP protocol:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">.\\Client\\bin\\Release\\Client.exe $LB_HTTP_DNS\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/9c72d4602e264118910c590eb7ad673a_image.png\" alt=\"image.png\" /></p>\n<p>Test the NetTCP protocol:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">.\\Client\\bin\\Release\\Client.exe $LB_NETTCP_DNS\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/08a0aacd9c3741dabb29c506677de058_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Clean_up_205\"></a><strong>Clean up</strong></h5>\n<p>Use the following command to clean up the resource:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">cd ..\\..\\Replatforming\ncopilot app delete\n</code></pre>\n<p>There are a few implications due to large container size:</p>\n<ul>\n<li>When using Amazon ECS or Amazon EKS with Amazon EC2, ensure that underlying storage has enough free space to spin up new container instances as required.</li>\n<li>Ensure the container image repository is closer to the compute (Amazon EC2 instance or Fargate), ideally using Amazon Elastic Container Registry (Amazon ECR) in the same Region to reduce download time. This in turn reduces the startup time and data transfer charges. You can <a href=\"https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/\" target=\"_blank\">implement cache strategy</a> to avoid expensive operations on the disk and shorten the container startup time.</li>\n<li>Containers startup time must be taken into consideration from an architecture and operation point of view. With a spiky workload, it is important to ensure the number of running containers is able to handle the spiky traffic. You should also consider using time-based auto scaling to handle predictable traffic.</li>\n</ul>\n<h4><a id=\"Refactoring_using_Core_WCF_221\"></a><strong>Refactoring using Core WCF</strong></h4>\n<p>In this example, we will modernize the server-side application to .NET 6 using Porting Assistant for .NET and Core WCF. Thanks to Core WCF, all the API contracts remain the same; thus, the client application will not be changed. To find out about using Porting Assistant for .NET, please refer to the blog post on <a href=\"https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/\" target=\"_blank\">Modernizing legacy WCF applications to Core WCF using Porting Assistant for .NET</a>. The following is the architecture for this example.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/e0f70f18481d49a2bf7613760dc9d988_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Dockerfile_226\"></a><strong>Dockerfile</strong></h5>\n<p>Here is the Dockerfile for the modernized solution with the following notes:</p>\n<p>We use Microsoft’s standard images; however, customers can use other base images with .NET 6 SDK and runtime installed.<br />\nTwo ports are exposed on the container: <code>80</code> (HTTP) and <code>808</code> (NetTCP).<br />\nThese base images are Linux-based; hence, switching to Linux containers is required on Docker Desktop.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/cb1ec357dde749a1afa2ed25a2540bd7_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"Deploy_ECS_cluster_235\"></a><strong>Deploy ECS cluster</strong></h5>\n<p>Create a new ECS cluster using the following commands:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">git clone https://github.com/aws-samples/containerization-options-for-wcf \ncd containerization-options-for-wcf/src/Refactoring\nmkdir copilot/refactoring\n@'\nname: refactoring\ntype: Load Balanced Web Service\n\nhttp:\n path: &quot;/&quot;\n healthcheck:\n path: &quot;/health-check&quot;\n success_codes: &quot;200&quot;\n healthy_threshold: 3\n unhealthy_threshold: 5\n interval: 15s\n timeout: 10s\n grace_period: 45s\n\nnlb:\n port: 808/tcp\n target_port: 808\n\nimage:\n build:\n dockerfile: Dockerfile\n port: 80\n\ncpu: 4096\nmemory: 8192\ncount: 2\nenvironments:\n test:\n count: 2\n deployment:\n rolling: &quot;recreate&quot;\n'@ | Out-File ./copilot/refactoring/manifest.yml\ncopilot app init wcfrefactoring\ncopilot init --name refactoring --type &quot;Load Balanced Web Service&quot; --deploy\n</code></pre>\n<p>Inspect the size of the container image:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">docker images --format &quot;{{.Repository}}: {{.Size}}&quot; &quot;*/wcfrefactoring/refactoring:latest&quot;\n</code></pre>\n<p>It is about 117 MB compared to 8.2 GB in the previous example.</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">444455556666.dkr.ecr.ap-southeast-2.amazonaws.com/wcfrefactoring/refactoring: 117MB\n</code></pre>\n<h5><a id=\"Testing_294\"></a><strong>Testing</strong></h5>\n<p>Build the client application:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">$LB_HTTP_DNS = (copilot svc show --app wcfrefactoring --name refactoring --json | jq -r .routes[0].url).Split(&quot; &quot;)[0]\n$LB_NETTCP_DNS = (copilot svc show --app wcfrefactoring --name refactoring --json | jq -r .routes[0].url).Split(&quot; &quot;)[2]\ncd ../CurrentWorkload/Client\nMsBuild.exe Client/Client.csproj /property:Configuration=Release\n</code></pre>\n<p>Test the HTTP protocol:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">.\\Client\\bin\\Release\\Client.exe $LB_HTTP_DNS\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/e38a2f1294914a998a60291c7978ad33_image.png\" alt=\"image.png\" /></p>\n<p>Test the NetTCP protocol:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">.\\Client\\bin\\Release\\Client.exe $LB_NETTCP_DNS\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/b1c3e0ec25374f50916f2792584ce1aa_image.png\" alt=\"image.png\" /></p>\n<p>In this example, we deployed a modernized WCF workload to Amazon ECS with Fargate. The workload is license-free, is significantly smaller in size, has a quicker startup time, and is highly optimized, hence requiring smaller compute and storage requirements while offering better overall performance.</p>\n<h5><a id=\"Clean_up_325\"></a><strong>Clean up</strong></h5>\n<p>Use the following command to clean up the resource:</p>\n<p>PowerShell</p>\n<pre><code class=\"lang-\">cd ..\\..\\Refactoring\ncopilot app delete\n</code></pre>\n<h3><a id=\"Conclusion_334\"></a><strong>Conclusion</strong></h3>\n<p>In this blog, we walk you through different options for migrating and modernizing WCF workloads onto one of the AWS container services. Replatforming is more suitable for workloads that require minimal application changes and maintain backward compatibility. Our customers can also benefit from refactoring the workloads onto a modern .NET using ASP.NET Web API, gRPC, or Core WCF. The refactored workloads work across platforms and can be run on both Linux and Windows containers, hence enabling customers to fully realize the benefits of containerization.</p>\n<p>Customers are also encouraged to check out the following resources:</p>\n<ul>\n<li><a href=\"https://aws.amazon.com/blogs/modernizing-with-aws/aws-app2container-support-for-windows-on-aws-fargate/\" target=\"_blank\">AWS App2Container</a></li>\n<li><a href=\"https://aws.amazon.com/blogs/modernizing-with-aws/migrate-wcf-apps-to-wcfcore-using-porting-assistant/\" target=\"_blank\">.NET Porting Assistant</a></li>\n<li><a href=\"https://github.com/CoreWCF/samples\" target=\"_blank\">Core WCF samples</a></li>\n<li><a href=\"https://github.com/CoreWCF/announcements\" target=\"_blank\">Core WCF announcements</a></li>\n<li><a href=\"https://docs.microsoft.com/en-us/dotnet/framework/wcf/\" target=\"_blank\">WCF official documentation</a></li>\n</ul>\n<p><img src=\"https://dev-media.amazoncloud.cn/49a427a84e1540bebf692e43093cadb2_image.png\" alt=\"image.png\" /></p>\n<p><strong>Minh Tuan Huynh</strong></p>\n<p>Based in Melbourne, Australia, Tuan is a Cloud Application Architect at AWS focusing on Applications Migration and Modernisation. He enjoys helping customers to achieve their business outcome through transformation &amp; modernisation. Outside of works, he is a big fan of soccer, loves road trips, travelling with family members and friends, and passionate in making his house more energy-efficient and smart.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/350d4b0b31a64ad1808b9fe7bbba0781_image.png\" alt=\"image.png\" /></p>\n<p><strong>Haofei Feng</strong></p>\n<p>Haofei is a Senior Cloud Architect at AWS with 16+ years experiences in Containers, DevOps and IT Infrastructure. He enjoys helping customers with their cloud journey. He is also keen to assist his customers to design and build scalable, secure and optimized container workloads on AWS. In his spare time, he spent time with his family and his lovely Border Collie. Haofei is based in Sydney, Australia.</p>\n"}