If you, like many others, are stuck with the old ASP.NET technology stack and don’t know how to start migrating your application to ASP.NET Core, This article will be an excellent opportunity to learn how you can leverage the benefits of modernisation before migrating your entire application. We will focus on three delivery strategies that can simplify this slow and challenging process: Dark Launching, Strangler Fig Pattern, and Canary Release.
Context and Problem
.NET Framework, a proprietary software framework developed by Microsoft that runs primarily on Microsoft Windows, has been on the market for over 20 years. ASP.NET extends the .NET Framework platform with tools and libraries specifically for building web apps. It was the predominant implementation of the Common Language Runtime until being superseded by the cross-platform .NET project.
Since its release, multiple applications have been built with .NET Framework using a monolithic approach, often becoming huge applications with thousands of lines of code. In addition, many are still on versions that reached end of life support years ago, making it a high-security issue for those still on the arduous journey of modernising their current tech stack.
Large applications are tough to migrate in one go and take a long time for businesses to start seeing results, which is where incremental migrations strategies come in. In the following sections, we will talk about how you can mitigate the risks involved with modernisation by applying some delivery strategies that can help you react fast and avoid the pitfalls of a large migration performed in one go.
Dark Launching
With Continuous Delivery, developers are under pressure to deliver new features faster than ever and get earlier feedback from those features. Dark launching assists in that feat: this method allows you to release new or change existing features to users without them knowing they’re there.
A dark launching strategy can also assess the system’s additional load and performance impacts before publicising the new capability. Or, in our case, it can be used to validate that a newly migrated API or endpoint is behaving as expected.
Strangler Fig pattern
Martin Fowler, a British software developer, author, and international public speaker introduced the term “strangler fig pattern” as a metaphor for a plant that begins as a vine in the upper branches of an older tree. As the vine grows, it starts strangling and killing the old tree until it replaces its host completely, leaving a new, strangler fig tree in its place.
In the context of modernising ASP.NET applications, this pattern incrementally replaces a legacy system by slowly substituting specific slices of its functionality through establishing proxies where other systems rely on web services. These proxies initially act as a pass-through behaviour because the existing monolithic fulfills their implementation. As the legacy system’s features are replaced, the new one eventually substitutes all of its components, strangling the old application and letting you decommission it.
The image above shows how one of the monolith’s endpoints on an AWS EC2 instance was replaced by its new version deployed on ECS. AWS Application Load Balancer is acting as a proxy. Once the latest version is ready, we can change the proxy to forward requests to the new version. This process will repeat until there’s nothing else left on our monolith, leaving only our new strangler fig application in its place.
Canary Release
A useful technique that can be applied whenever you need an early warning for problems before impacting all your users is Canary Release. Utilising another metaphor, this technique stemmed from the technique used by miners who carried a canary in a cage into the coal mines. If toxic gases leaked into the mine, the canary would die, warning the miners and saving them from eventual death. A Canary Release strategy provides a similar early warning for potential problems before impacting your entire user base. This strategy can lower the risk of introducing a new software version in a production environment by gradually releasing your new or updated feature to a small portion of users before making it available to everyone.
Another benefit of using this strategy is running capacity tests of your new version directly in production environments with a safe rollback strategy if any problems or failures are detected.
In the image above, we are releasing the new version of our application to only 20% of our users before making it available to everybody. So, if any problems are detected, only that small portion of users would be affected, and we could easily roll back the changes.
Final thoughts
There are a number of reasons why the migration of ASP.NET applications is slow and complex. However, now you know that a number of existing strategies can help you avoid significant issues and leverage the benefits of migrating small pieces of your app in an incremental way. With these strategies, the size and complexity of your systems no longer need to be a barrier to modernisation.
DNX Solutions has experience in migrating large monolithic applications, and are more than happy to assist you and your team during the process. To find out which strategies would best suit your business needs, get in touch with a DNX expert today.
Additional Links for further reading
Contact a DNX expert to book a free 15-minute consultation and explore your possibilities for Cloud Migration
