Modern applications capabilities are expected to be secure, resilient, elastic, modular, automated and interoperable. Modern applications need to stay competitive, and digital businesses must innovate as rapidly as possible. The goal is to automate and abstract away as much as possible so our customers can focus on building modern applications for their business. To win customers, the entire focus is on decoupling the software systems and creating the business logic, which can help them experiment and innovate more often, build better products and release features faster.

Business challenge

Let’s begin with a .NET monolithic application that is deployed on-premise where all the services are interconnected and is running behind a load balancer with the sticky session, because the session is stored locally on the local web server and it is backed by single monolithic database server.

This application will work fine on AWS, but it will have some limitations, including:

• Difficulty scaling efficiently
• Reliability challenges
• Difficulty iterating quickly
• Continuous integration/Continuous deployment that is time consuming

Eventually this application will need to go through some sort of re-architecture or re-factor to maximize the investment on AWS. We will deep dive into all the possible modernization options.

But first, let’s look at key elements of the traditional applications and desired end state of each component. The below diagram represents the mapping between the traditional services versus modern services on cloud. These are pathways to modernize. For example, Waterfall to Agile methodology is one of the big-ticket items and is one of the key components that allows the development team to move quickly, iterate and fail fast. This is a centralized operations approach where the operations team manages everything and, thereby, moves to DevOps team where he individual development team is responsible for the lifecycle of a modern service.

Solution

Before we delve into .NET common modernization patterns, let us briefly discuss the 7 R’ migration patterns: 7 common migration strategies for moving applications to the cloud. These strategies build upon the 5 Rs that Gartner identified in 2011 and consist of the following (as defined by AWS):

Re-host (lift and shift) – Move an application to the cloud without making any changes to take advantage of cloud capabilities. Example: Migrate your on-premises Oracle database to Oracle on an EC2 instance in the AWS Cloud.

Re-platform (lift and reshape) – Move an application to the cloud and introduce some level of optimization to take advantage of cloud capabilities. Example: Migrate your on-premises Oracle database to Amazon Relational Database Service (Amazon RDS) for Oracle in the AWS Cloud.

Re-factor/ Re-architect – Move an application and modify its architecture by taking full advantage of cloud-native features to improve agility, performance and scalability. This typically involves porting the operating system and database. Example: Migrate your on-premises Oracle database to the Amazon Aurora PostgreSQL-Compatible Edition.

Repurchase (drop and shop) – Switch to a different product, typically by moving from a traditional license to a SaaS model. Example: Migrate your customer relationship management (CRM) system to Salesforce.com.

Relocate (hypervisor-level lift and shift) – Move infrastructure to the cloud without purchasing new hardware, rewriting applications, or modifying your existing operations. This migration scenario is specific to VMware Cloud on AWS, which supports virtual machine (VM) compatibility and workload portability between your on-premises environment and AWS. You can use the VMware Cloud Foundation technologies from your on-premises data centers when you migrate your infrastructure to VMware Cloud on AWS. Example: Relocate the hypervisor hosting your Oracle database to VMware Cloud on AWS.

Retain (revisit) – Keep applications in your source environment. These might include applications that require major refactoring, but you want to postpone that work until a later time, as well as legacy applications that you want to retain, because there’s no business justification for migrating them.

Retire – Decommission or remove applications that are no longer needed in your source environment.

The following are some of the key patterns we see when we work with the customers, be it on greenfield application development or modernizing the existing applications.

• Replatforming to cloud native -Incremental modernization with automation and replacement for databases, messaging, API management, logging, monitoring, and alerting. The application can take advantage of cloud native services. This process reduces the operational overhead and focuses more on the applications.
• Container adoption – With minimal changes to the application, leverage microservices or modular architecture to improve scalability, resource usage and lower operational overhead. We see container adoption being a common approach these days by taking the base application and breaking it into microservices, isolating the functionality to improve scalability. It also helps to take advantage of even more scalability and a faster development cycle.
• Refactoring to serverless -Refactor to leverage serverless architectures, which offer the highest efficiency and cost benefits of the cloud by pushing nearly all infrastructure and software management to the platform. Extensive work may be involved in refactoring to serverless.  This process takes  advantage of underlying services such as Lambda or DynamoDB, which are completely managed by AWS.

Modernization option – Re-platforming:

Let’s deep dive into these patterns. In terms of modernization, the first easy step here would be re-platforming the application and using more of cloud native services. Some cloud optimization is done for the application to achieve tangible benefits, for example:

• Changing application functionality to be stateless and storing the session data in a distributed cache so that it need not be stored in load balancer, and then wrapping the front-end web servers into an auto-scaling group to get the benefit of elasticity in the cloud.
• Supporting services such as logging and monitoring of more of cloud native services to get better observability of the application.

Overall, the core architecture of the application is not changing when you are looking to re-platform your application. In addition, on-premises database migration can be migrated to managed database service (RDS). For .NET framework applications, you can look to containerize your application to windows containers to optimize the operating system utilization and achieve runtime consistency.

Modernization option – Container adoption and refactoring to serverless:

With this option, many customers are looking at moving from a .NET framework to .NET Core on AWS to unlock
the cost saving and increase productivity. Going serverless is the primary goal of decomposition, as this would be the cost efficient and performant architecture where the team focuses on business logic and completely sourcing out the need to take care of the infrastructure to AWS. Also refactoring and rearchitecture usually go side by side when you are rewriting your code or refactoring your application or splitting your monolithic to microservices and moving business logic to microservices. At the same time, we may also want to look into more of purpose-built NoSQL databases where eventual consistency is acceptable so that you can remove the more expensive, hard-to-scale relational databases and use the purpose-built NoSQL database available in AWS. When we decompose the monolithic application to microservices, an orchestrated approach with a container can also be a valid option. A key point to note is that not all the services that are decomposed from monolithic will immediately fit into Lambda, and the right choice may be to go into containers and slowly, when they fit better into Lambda, you can migrate those to Lambda and make it more event driven. In many cases, customers run their Lambda and containers to co-exist together in production at the same time. Serverless enables you to focus on business logic by removing the heavy lifting activities performed.

Evolution of .NET Framework

.NET Framework has been in production since 2002 where this was supported in Windows NT, Windows Server 2000 operating system. Today, many customers are looking at moving to an open source model where anyone can contribute and collaborate. Microsoft developed .NET (previously named .NET Core), which is a free and open source framework for Windows, Linux and macOS operating systems. It is a cross-platform successor to .NET Framework.

Why choose AWS Cloud for hosting .NET applications?

AWS Cloud provides a strong foundation for hosting modern application with .NET 5 on AWS. .NET can be used in various target operating system like Windows, Linux, MacOS, iOS, Android, tvOS, watchOS and more. AWS supports a broad range of development tools to support the .NET modernization. See Figure 4 for the broad range of development tools supported on AWS.

Source Image: https://devblogs.microsoft.com

Development tools on AWS

AWS provides a range of developer tools, software development kits (SDKs) and CLIs to improve the .NET developer experience.

AWS Compute Services for .NET

Let’s look at what compute choices are available to host .NET applications on AWS. We have number of choices depending on what modernizing paths you decide to take and what you are using. If you are targeting .NET framework applications, then options like EC2, Elastic Beanstalk, ECS and EKS are available. For rehosting, EC2 can be used. Elastic Beanstalk can also be used, which automatically handles the deployment, capacity provisioning, etc. With regards to replatforming, if you are using docker containers, ECS can be used to manage containers. If you are using Kubernetes, then you can use Amazon EKS. If you are using .NET Core / .NET 5, you have the first 4 options. Additionally, you can also run your services on AWS Fargate to orchestrate those containers, and you can also use AWS Lambda, which is serverless function technology.

Please refer to the below flowchart to decide whether applications need to be rehosted or replatformed or move to serverless.

The below figure highlights the mapping of AWS tools and services with the IBM offerings.

Containerize and migrate existing applications using AWS App2 Container:

• Streamline operations by containerizing your existing applications, and standardize on a single set of tooling for monitoring, operations and software delivery.
• Analyze your applications and automatically generate a container image that is configured with the correct dependencies, network configurations, and deployment instructions for ECS / Kubernetes or App Runner.
• Easily deploy an existing application on the cloud that is provisioned with the correct networking and security configurations.

Porting Assistant for .NET

• Scans your entire .NET Framework application portfolio to generate .NET Core compatibility assessment reports. This makes it easy to prioritize applications for porting based on the level of effort required.
• Identifies incompatible .NET Core APIs and packages from your .NET Framework applications, and finds known replacements, reducing the manual effort of searching for replaceable packages and APIs.

Windows Web Application Migration Assistant (WWAMA)

• The Windows Web Application Migration Assistant for AWS, Elastic Beanstalk, is an interactive PowerShell utility that migrates ASP.NET and ASP.NET Core applications from on-premises IIS Windows servers to Elastic Beanstalk.
• The migration assistant is able to migrate an entire website and its configuration to Elastic Beanstalk with minimal or no changes to the application. After the assistant migrates the application, Elastic Beanstalk automatically handles the ongoing details of capacity provisioning, load balancing, auto-scaling, application health monitoring and applying patches and updates to the underlying platform.
• The migration assistant interactively walks you through the steps shown below during the migration process:
  • Discover local websites
  • Select site to migrate
  • Discover database connection strings
  • Update database connection strings
  • Generate Elastic Beanstalk deployment bundle
  • Deploy application to Elastic Beanstalk

References:

https://aws.amazon.com/porting-assistant-dotnet/

https://aws.amazon.com/app2container/

https://aws.amazon.com/blogs