What are the benefits and challenges of migrating from a monolithic to a microservice system?

- Independence about feature, module, source code, database . - Easy to scale service . - Reach zero downtime . - multiple language, framework, technical of microservices . - Highly available . - Easy to deploy instance. - Can reuse logic or data like "write once, use any where" .

Migrating to microservices from monolithic architecture enhances scalability, allows team autonomy, and enables the use of diverse technologies for different services. However, it introduces complexities such as a steep learning curve in domain-driven design, intricate inter-service communication, and ensuring data consistency across distributed systems. Additionally, it necessitates a significant shift in organizational development style, requiring a more collaborative, cross-functional approach and often a change in team structures and company culture. This transition demands a deep understanding of microservice patterns and robust data handling strategies like event sourcing and sagas.

In my agile method of development cycle expericne having microservice on each phase benefits as follows, Design Phase: - Own Tech stack and Pace including the data scheme Development Phase: - Independent development by owning the source code - Easier local and developmental deployment for testing purpose Deployment on Production: - Flexible scalability - less system wide failure due to isolated faults

Microservices architecture provides numerous advantages for modern software development. By breaking down applications into smaller, independently deployable services, teams gain scalability, flexibility, and agility. Each service can be developed, deployed, and scaled independently, fostering faster development cycles and easier maintenance. Fault isolation ensures that failures in one service do not bring down the entire system, enhancing resilience. Additionally, microservices enable teams to leverage diverse technologies and optimize each service for its specific function, improving overall system performance and fault tolerance.

[pt-br] Microsserviços se baseiam fortemente no conceito de modularização em torno de domínios de negócio. Além disso, compartilham dos mesmos princípios de design que emergem da Service-Oriented Architecture (SOA) e sua adoção pode trazer benefícios como rápido time to market, maior dinamismo em relação às mudanças, redução de custos e aplicações mais escaláveis e robustas. [en-us] Microservices strongly rely on the concept of modularization around business domains. Additionally, they share the same design principles that arise from Service-Oriented Architecture (SOA). Their adoption can bring benefits such as faster time to market, greater dynamism in response to changes, cost reduction, and more scalable and robust applications.

Although Microservice Architecture brings about a new perspective on developing distributed systems with benefits like Team Autonomy, Using Polyglot architectures with different Tech Stacks and selective scaling of the services, they do come with some challenges and complexities. The major being a large learning curve for the developers and architects. Based on the SOA architecture and the Domain Driven Design Principle, so it requires the understanding of the various concepts like Entity, Domain, Aggregates, Bounded Context along with various communication medium, message brokers, cross-cutting concerns and data handling patterns like Event Sourcing and Sagas.

One of the advantages of MSA (Microservice Architecture) is that services can be deployed just-in-time. What if there is no/low connectivity (due to various reasons) to download and deploy the microservices? Just-in-time is necessary to optimize compute resource usage. But, functionality may not exist when it is needed impacting user experience. In automotive systems, we are working on an approach to address this. We are in process of filing a patent on this. Will post after it is granted/published. Are there any well-known approaches to address this? Keeping this question open to get views of others

May be you get some problems about: - Design module, feature, database from current project (monolithic). - Define 1 base service like example component with basic feature which can join a microservice system. - Must learn to use a lot of technical such as message broker, load balance, cache, elk, discovery service... - Hard for beginner to develop or debug code service. - Some issue security when service communicate other service. - Build a lot of monitor, log system for each technical to manage performance, issue which occur any time in any environment.

Creio que o maior desafio é quando não usar. Nem sempre é necessario criar um microsserviço para se "resolver" algo. Se deixar levar pela ideia que o microsserviço resolve tudo, vai encarecer muito a estrutura e, criará uma morosidade desnecessária.

The main challenges I see in companies are: Knowing how to isolate correctly, data replication and consistency, traceability and of course, I couldn't fail to mention the 8 fallacies of distributed computing and Conway's law.

The first step before migrating is to undergo a domain-driven design journey to map out business contexts. Afterward, defining coexistence strategies is crucial to implement an evolutionary approach, such as employing an Anti-Corruption Layer (ACL) to integrate with legacy systems.

Migration monolithic system to microservices, for me will this point: i) Identify a function which you wanted to move to microservices and start from there. Internal microservices will be good start point. ii) Don't boiled the ocean, choose a technology stack you must have, then you can be built from there. iii) Build layer architecture, core api, integration api and the frontend api. You can easily build from this layer.

Migrating from monolithic to microservices requires careful planning. Understand the monolith, start with low-risk components, and decompose incrementally using domain-driven design. Establish clear service boundaries and communication patterns, ensuring fault tolerance. Invest in monitoring tools for insights, automate deployment with CI/CD pipelines, and address data management challenges. Continuously monitor and iterate for optimization and issue resolution.

I think you should begin by step below: - Analyze construct, business, feature of current project (monolithic). - Build all component which is necessary for your microservice system like proxy, api gateway, service discovery, message queue, container, cache. - Build monitor of above component system which is useful for development and maintenance. - Build a new microservice which is split (feature) from current monolithic project. - Switch to use new microservice by endpoint or message queue instead of call method module in current project, make sure current project is ready to join your microservice system and communicate with new microservice. - Finally, monitor and test careful for above migration so long.

What will be the trade off? Are you clear about the business requirements you are seeking to achieve? If you don't know exactly what you're giving up and what you want to achieve, don't migrate.

I will recommend these 4 stages for the whole process, - Define Boundaries: Pinpoint independent features within the large, single application. - Break Apart: Separate these features into distinct components. - Communicate Efficiently: Use tools like RabbitMQ or Kafka to allow components to talk to each other without delay. - Go Micro: Deploy each component as its own mini-service, making them easier to manage and scale.

I prefer to separate the migration in the Software Reengineering Process followed by a DevOps process. The reengineering part consists of a Reverse Engineering phase followed by a Forward Engineering phase. The Reverse Engineering phase corresponds to the Analysis activity, whereas the Forward Engineering phase comprises the Design, Code, and Test activities. Moreover, the DevOps part of the process consists of a CI + CDE + CD phase followed by a Monitoring phase, corresponding to the Delivery, Support, and Feedback activity.

En mi experiencia Lo mas fácil fue meter el monolito como si fuera un micro mas y tratarlo como tal. Al tratar al monolito como un micro mas ganamos todas las ventajas de los micro servicios. El monolito seguía funcionado e interactuando con los otros micro servicios que se iban creando.

The new technologies available in the cloud environment and the dynamic nature of continuous innovation demand microservices strategies to maintain a continuous flow of innovation within companies. A modern architectural approach necessitates a DevOps strategy (GitHub / Azure DevOps), cloud monitoring tools, good software architecture practices, as well as a managed Kubernetes environment in the cloud, such as Azure AKS, Google GKE, AWS EKS. Advancing stages may involve utilizing development platforms like Devprime, offering production-ready microservices in seconds.

Tome cuidado com a segurança, nada deverá ficar exposto. Use ferramentas para monitor disponibilidade e latência. Tenha gestão dos serviços. Gerencie os custos para que o serviço não se "auto-escale" sem necessidade.

Los micro servicios no son para todas las empresas para todos los equipos. Hay muchas cosas que se tienen que tomar en cuenta antes de lanzarse a hacer micro servicios y matar el monolito.

Just be careful with the decision of migration, only consider if its worth enough the additional overhead the microservices brings not every solutions need microservices.