AWS MAP (Migration Acceleration Program) has been around for several years. Before the program was announced, the most common terminology used for migrations was “Lift&Shift”which means migrating “as-is”. The following other approaches are usually considered as “Replatforming” and “Refactoring”. The following diagram is showing different path alternatives for the migrations:
Ref: https://aws.amazon.com/blogs/enterprise-strategy/cloud-native-or-lift-and-shift/
As kloia, we have been focusing on Application Modernization projects by 2015 which including code refactoring or rearchitecting. Together with a such software modernization, the opportunity for Replatforming (Hosting the software on container/Kubernetes/Serverless) becomes also possible. The reality is, without refactoring, there is low value coming with “Lift&Shift” of the legacy applications. By 2018, AWS included Application Modernization as a program under “Microsoft Workloads Competency”. The following is a reference from an AWS Blogpost regarding .NET Modernization pathways:
As one of the first four “Application Modernization” partners of AWS around the world, we have completed several modernization projects. Three of them are published under the AWS Blog:
Kloia approach for .NET Application Modernization is not limited only with .NETCore transformation, but also includes several solutions to generic software architectural problems. Our typical approach for modernization begins with understanding the business domain and preparing a modernization roadmap that supports the business. The following describes the steps of our approach:
During modernisation projects, Kloia leverages an iteration based approach. And all projects have a dedicated cross functional team (including analysts, developers, DevOps engineers and QA engineers )
For instance, a transition from on-premise desktop client to web application has short term and long term solutions. For short-term, there are several techniques for WebRun, which do not need code change. For a long term solution, we first set an anti-corruption layer(ACL) to let the incremental changes for further iterations. And using strangler fig pattern, we move the functionality step step to the web based app. Based on the requirements, we usually suggest React based UI with reactive backend wherever applicable.
Regarding mitigating potential issues, we always propose several alternativesand choose the appropriate one together considering the risk, budget and strategy.
This type of modernisation involves replatforming and refactoring , which affects the infrastructure by including new AWS services. This usually results in transition from IaaS to more PaaS services, including managed DBs, managed container services, even including serverless Lambda services. In our experience, resource utilization of EC2 for non-container environments is low, usually 5% to 15% on average. After transition to containers, resource utilization increases, and depending on your policies, it can go up.
On the other side, together with the new .NETwhich works on container/Linux OS, dewindowsification also results in cost reduction.
There will also be some cost increases, together with new WebUI, as Desktop Applications does not require a server, but with new UI technology, we need to introduce new servers as well. Besides, based on the data model, we may be using new database alternatives including DocumentDB or QLDB which may bring additional AWS services.
Having such new technologies will bring flexibility and robustness to the infrastructure. It will also be possible to implement Disaster Recovery for the new infrastructure much easier than with the existing legacy set up.
Referring to our previous experience of hybrid-cloud migrations and environments where the workload is spread between on-prem and AWS, companies usually tend to benefit their existing invested technologies and tools, including:
This list is not exhaustive, and may grow depending on the existing tools. Our recommendation is that a transition should not be limited with the functionality of the existing tools/technologies.
Besides, based on our previous track record on database modernisation , both on RDBMS and non-relational alternatives, including -
Database modernization depends on the data model and data requirements. In our experience, no business should exist only with an RDBMS! Introducing QLDB to track records which helped them for compliance or modernizing from MSSQL to serverless Aurora and DocumentDB are some examples we have been through.
The current AWS MAP has restructured the migration process in to 3 phases:
Ref: https://aws.amazon.com/migration-acceleration-program/
Here are what is expecting in each step:
Here is a visualized version of MAP steps:
As I have described in the beginning of this blogpost, our previous experience regarding Modernize (Within the last section in MAP) helps us to find an optimal experience for the AWS Migration projects. There is no single modernization project where we didn’t introduce a new Database or a new approach for cross-cutting concerns.
As a conclusion, our approach to modernization has been evolving with a collective experience that we have gained through the projects. We can observe in the market that still
These numbers show that cloud adaptation also needs a major focus on software refactoring to get the maximum benefit from the cloud.