Re-architect
Re-architecting for migration focuses on modifying and extending app functionality and the code base to optimize the app architecture for cloud scalability. This option is considered when want to modify or extend the code base to align more with modern approaches to scale and optimization.
For example, if your existing application is resource intensive, it may cause larger cloud billing because it involves big data processing or image rendering. In that case, redesigning the application for a better resource utilization is required before moving to the cloud. You could consider splitting this application into independent microservices and scale only the service based on the usage or performance requirements.
Re-architecting is the preferred option when:
You are migrating an application that need maximum agility, scalability and flexibility in the cloud.
Your application is hard to independently deploy, test and manage
Certain features/ part of the application needs more capacity and resources than the rest.
You need to start this approach by finding parts that can be carved off from the main application and moved into separate small services or resources in the cloud. Its always good to start looking into business logic in the application code which can be separated into a independent application. For example, you could break down a monolithic application into a group of microservices that work together and scale easily. Or, you could re-architect relational and non-relational databases to a fully managed database solution, such as Azure SQL Database Managed Instance, Azure Database for MySQL, Azure Database for PostgreSQL, and Azure Cosmos DB.
Pros of this approach are:
Allows you to create a highly scalable, resilient application
Easier deployment and testing of independent applications that benefit from a loosely couple architecture.
Can create an application that leverage the full power and features of Azure cloud.
Wide range of services to choose from the Azure stack like (event grid, cosmos db, service bus, Azure AD etc.)
Cons of this approach are:
Complex and expensive migration with a high risk of faults and service disruption in the early deployment stages compared to the lift & shit and refactor approach.
Increased number of connections between multiple modules and databases, would mean that requests, transactions etc. should be handled very carefully.
References:
#cloudmigration #cloudadoption #azureadoption #azuremigration #cloudarchitect #cloudsolutionarchitect #cloudpatterns #aks #servicemesh
Comentários