You're facing a legacy system migration. How do you decide which components to move to microservices first?

Quando se fala em migra??o, podemos dizer que estamos mudando um estado de um evento. Seja ele físico ou lógico. Toda mudan?a necessidade de um projeto. é um projeto segue determinadas etapas. Essas etapas nos garante a visibilidade, tempo aproximado, os riscos que iremos encontrar durante o andamento do projeto, implementa??es, etc. Um ponto importante, antes de trocar os pneus de um Boeing 747 devemos atentar na troca dos pneus do avi?o teco teco. Experiência e histórico uma das chaves principais do sucesso de um projeto.

- I'd first try to measure which flows in our systems are the ones that are the most common, and most frequently called upon. - Then, I'd try to rank the flows that the legacy systems are taking place, or even are the primary entities to manage them. - After that, I'd take the most critical services or systems, according to the previous rankings, and build a plan that will allow migrating them to microservices by splitting responsibilities that they shouldn't have for example, put them in other services, or even create from them multiple microservices as needed. - I'd do that process for each system step-by-step, but I'd probably start with the most frequently used with the combination of hard-to-manage that decreases R&D velocity overtime

API First Strategy: Evaluate legacy components for microservices migration, focusing on scalability, availability, latency, and real-time improvements. Use frameworks like Spring Boot to accelerate API development. API vs. Near Real-Time Event Processing: For near real-time (background) operations, use asynchronous processing with RabbitMQ or Kafka, improving resource utilization and performance. API vs. Batch Processing: Use batch processing for large data volumes or scheduled operations, determining frequency based on business needs. Effective when real-time processing isn't essential. Following these steps ensures the new microservices architecture adapts to modern changes.

1. I have found the Stranger pattern to be quite handy during system migration, as it allows for a gradual replacement of the legacy system rather than a big-bang approach. This provides ample time to observe the modernized system's behavior and boosts stakeholders' confidence in the legacy system replacement. 2. The Four Rs are essential during legacy system migration: re-host, re-platform, re-factor, or replace. Deciding which approach to take is crucial for a successful migration.

To decide which components of a legacy system to move to microservices, it's essential to have a solid justification beyond following trends. Prioritize components with a direct business impact, frequent changes, or criticality to isolate failures. Evaluate scalability, performance, and maintenance needs. Components with fewer dependencies or those heavily coupled are also good candidates. The migration should aim for specific improvements, such as increased performance and agility, rather than being done just for the sake of fashion. Utilize K8S or OpenShift for effective orchestration and management.

I assume legacy migration means the old system is to be retired. Would start off with mirroring data from legacy to the new DB/schema so data is available on both systems. Then move the independent components like reporting, UI etc. to the new system. After that move all the core and backend components are moved to the new architecture- ensure the in bound data is fed to DB on both the old and new architecture/instances. Keep the old DB around till we are sure everything works as expected. Then stop the data entering the legacy system and take the plug off the old DB.