.NET Tutorial: Modernize Existing .NET Applications
Is cloud-native right for your .NET application?
Join the DZone community and get the full member experience.Join For Free
Together, with the Cloud movement and its functions and benefits, Software practices and trends have been converging towards creating or migrating the applications towards a Cloud-Native compliant architecture. This may include:
- Microservices, where you have independently deployable applications with their isolated data persistent layers, which are not shared along with other services.
- Polyglot architecture, where you are not tied to a homogenous stack with a single programming language. You can also use the data persistency option, rather using different language stacks for different purposes and also benefiting from several different types of Database and Datastore options.
- Containers, where you define all your application dependencies, thus guaranteeing the portability all the way from developer workstation to production.
- Serverless, where you split your application into functions and deploy those functions to a Cloud-managed cluster where you do not notice any underlying server and middleware maintenance and can define several options to trigger those services.
Furthermore, to all those evolving trends, the .NET Programming language is also adapting itself to those changes in the software industry. One of the major changes is cross-platform support.
.NET can also be built and run on Linux kernel-based operating systems, which brings cost-saving and also the option to run .NET on Kubernetes.
Besides, as .NET is open source, this affected the support from the community in a positive way. Together, with its lightweight architecture, which brings higher performance compared to the previous .NET versions, .NET Core is now the defacto version of .NET for all new projects. Migration efforts towards this version from the existing legacy applications have begun in mass.
Considering the progress and the trends both in software in general and also in .NET in particular, kloia is providing a multi-dimensional model for the .NET modernization. There are three main dimensions in this model:
- .NET Core Transition: The compatibility of the existing application or the newly developed application on .NETCore
- Splitting the Monolith: Identifying the existing bounded-contexts and splitting those contexts into microservices where each context is an independently deployable code including its Database.
- Cloud-Native: Exploiting the advantages of cloud computing delivery model including DevOps practices using the cloud resources managed resources like PaaS or serverless, considering a decoupled polyglot architecture model, and using Kubernetes as an orchestration platform.
There are three steps that can be illustrated as:
- Assess your current codebase and dependencies, create a report and roadmap
- The transition may have different paths based on the output of the initial step which makes an analysis of possible scenarios and also time cost-complexity of this is estimated. These are the possible scenarios:
- 2.a. Refactoring towards .NET Core
- 2.b. Redevelopment from scratch on .NET Core
- 2.c Modernizing with:
- 2.c.i. Mono-Project: Building and Running existing .NET applications on Linux with Mono, which is officially supported by Microsoft.
- 2.c.ii. Blazor: Build legacy .NET Windows UI applications, to be run inside a browser, thus modernizing the release cycle and cross-platform support, which is officially supported by Microsoft.
- Acceptance of the final state of the application.
This model covers various .NET application versions and types. Here is a basic chart of the coverage and possible paths:
Note: Dotted lines mean that this path will be evaluated during the assessment phase and the thicker the line, the higher the complexity.
There are four steps in that model:
Replatforming the current stack to a Cloud-Native state with micro-refactoring wherever needed. One example can be AWS Elastic Beanstalk. This step aims to get rid of current manual operations on infrastructure and deployments, thus increasing the focus of the team for the next phase.
Assessment of the current code-base with the following activities:
Pre-splitting tasks are crucial before the actual “major-refactoring” begins, the following pre-requirements should be done for the purpose of managing the unexpected incidents during the journey:
- Test Automation: Before the splitting begins, there should be enough regression test coverage which will run before each refactoring deployed to production.
- Monitoring: Creating full visibility of the current stack including:
- Metrics on all levels.
- Log Management.
Refactoring for splitting the bounded-contexts in the order which is agreed with the customer.
The functions, resources, and services provided by the cloud providers have been increasing and diversifying. It is very likely that you will find an equivalent service that you normally would develop yourself. Benefiting from those Cloud functions, in other words, the Cloud Native approach saves time and money.
Some of the Cloud functions that are introduced for those modernization projects are:
- Managed Resources (PaaS)Databases, Key-value Stores, Message Queues, EKS.
- ETL, Import/Export AWS Glue, Athena, EMR.
- Object StorageS3.
- TriggersVarious triggers after a specific event(i.e. File upload ).
Cost Saving: Various options together with Serverless, managed resources, auto-scaling(Even scaling to 0!), Windows OS License
Performance: Moving away from IIS means getting away from various overheads together with .NET Core’s lightweight and lean architecture which boosts performance
Cloud-Native: Cloud functions which make your development and deployment cycles less complex and manageable
Cross-Platform: Possibility to run your workload both Windows and Linux and even on Kubernetes!
- DotNetCore Transition
- Containerization and Serverless
- Splitting the Monolith
Good luck with your journey!
Published at DZone with permission of Dorian Sezen. See the original article here.
Opinions expressed by DZone contributors are their own.