Many customers face the challenge of actively developing core .NET framework applications whilst tackling the need to migrate or modernize to the cloud. Whilst migration can afford a “quick win” in making the initial push into the cloud, modernization should be considered the ultimate destination for organizations to make steps towards. By leveraging modern architectural patterns, customers can better achieve resiliency, performance efficiency, operational excellence, and business agility in the cloud. In this post, we’ll review the different modernization strategies for .NET applications on AWS, and what benefits can be realized for each strategy.
Rehost – This strategy can be used to quickly migrate applications to the cloud with no modifications and is useful when using commercial-off-the-shelf (COTS) software, to limit development changes on large scale applications, mitigate risk/time for migration, or when access to legacy application expertise or cloud skills are limited/unavailable.
AWS services that can be leveraged here include Amazon EC2 (if complete control of the compute environment is required) and AWS Elastic Beanstalk (if a managed environment is more appropriate for your workload).
While this strategy is typically of low effort and cost, it must be cautioned that the cloud native benefits of performance, scalability and resilience may not be fully realized. Typically, clients choose to rehost to be able to start the decommissioning of on-premise infrastructure sooner, but they a roadmap for modernizing further once in the cloud.
Replatform as a Windows container – This strategy allows the use of container technologies without core architectural changes and is useful if you’re unable to resolve Windows or .NET Framework dependencies or if the skills needed to refactor the application to .NET Core or .NET 6 is limited or unavailable.
AWS services include Amazon Elastic Container Registry (ECR) for storing container images and one of Amazon Elastic Container Service (ECS, if you need a simplified and fully managed container orchestration service), Amazon Elastic Kubernetes Service (EKS, if you want to take advantage of a managed Kubernetes environment) and Amazon EC2 (again for complete control of the compute environment, hosting Docker with Windows containers).
While this strategy allows better deployment options, improved utilization/security, and low effort to migrate, it still comes with Windows licensing cost considerations which may have otherwise been avoided. Often, we find that applications can be ported to .NET Core and run successfully on Linux containers with minimal effort, therefore it’s important to at least assess the complexity of refactoring required.
Re-architect as a Linux container – This strategy goes a step further, fully porting .NET Framework applications to .NET Core or .NET 6, and side stepping the Windows license costs of the previous strategy. It can be useful when resources/time is available for refactoring, .NET Framework dependencies can be resolved, and the application runs constantly.
AWS services are similar to the previous strategy, however the additional option of hosting on AWS Fargate (a serverless, pay-as-you-go compute engine) is also available, when choosing either of the ECS or EKS deployment options. Application can be analysed with the AWS Porting Assistant tool, https://aws.amazon.com/porting-assistant-dotnet/, to determine .NET Core compatibility.
Overall, this strategy can create a lower total cost of ownership along with accelerated innovation through cloud native architectures, however there is more upfront effort and cost necessary.
Re-architect as microservices in Linux containers – This strategy employs a decoupled, single purpose microservices architecture whereby the legacy application is broken down into a suite of smaller container services that run as their own processes within the application ecosystem. This strategy can also be considered when there are similar considerations to the previous strategy, as well as a need to break down a monolithic application into microservices.
There are several AWS services that can be leveraged in this strategy over and above the previously mentioned services. These include Amazon API Gateway (fully managed API service), Amazon Simple Notification Service (fully managed publish/subscribe service), Amazon Simple Queue Service (fully managed message queueing service), AWS Lambda (serverless, event-driven compute service) and Amazon Simple Storage Service (highly available, performant, and secure object storage service). AWS Microservice Extractor can assist in the process of decoupling monolithic applications and AWS Migration Hub Refactor Spaces can be leveraged to incrementally deploy microservices using the Stangler Fig pattern.
By leveraging this strategy, more cloud native benefits can be realized, such as faster innovation, higher availability, agility, and scalability; unlocked by smaller service footprints that make it easier and faster to deploy incremental and independent changes. Effort and cost are of course a consideration here, along with operational complexity that may be introduced depending on the architecture and resource skillset.
Re-architect as microservices without containers – This final modernization strategy leverages serverless compute environments alongside containers as best makes sense to break down the legacy monolithic application and should be considered over the previous strategy if there are also some applications that do not run constantly or run for a short period of time.
AWS services are similar to the previous strategy with additional use of AWS Lambda and potentially Amazon API Gateway for specific short-lived application components.
Additional advantages here include cost savings and reduced provisioning on the serverless resources; however, this of course does not support long-running applications (microservices on containers are then a better fit, either wholly or hybrid alongside).
—
Choosing the right strategy can be a tricky undertaking, especially when factoring all the variables and nuance to any organization, its business needs, and available skills. Customers frequently make the mistake of stopping migration and modernisation activities at the rehost or microservice stages, but it’s important to have a roadmap of optimisation activities to unlock the true benefits of the cloud. The best way to get started is essentially that: get started. Assess by identifying one or two application use cases, weighing up business outcomes and design considerations to explore different strategies. Modernize through execution to develop foundations, scalable patterns and to internalize learnings. Manage by developing operational best practices for the cloud and your new modernized estate.
