Microservices-based projects are a great idea to deliver products in less time and with great flexibility/agility. The major ways microservices-based projects help in quick deliveries are: Dividing the work into different services. Assigning the services to each squad to work independently: Parallelism of work Each squad having ownership of their own services. This looks rosy on paper but practically on the ground, this may turn up into a mess quickly if a few things are not taken care of. Squads working independently does not mean making themselves isolated from the bigger picture of business flow. Make sure each squad who owns the service, knows the business relevance/impact of the service they are writing. Else every squad defines the scope and design of the services based on their own limited knowledge which will result in ignoring several scenarios and use cases. Having services independent of each other does not mean there will be no common component: Few components should be carved as common else it will result in higher cost and reduce maintainability. Example of components which can be a good candidate for common structure: Datastore/ DataLake State of process Permission hierarchy Most important thing is to have the right cut/ boundary for the services. End to End (E2E) testing should be independent of services squad: We should not confuse E2E testing with component testing stacking up. Keeping this independent will bring much-required discipline in the different squad to align with a greater picture of business flow. Scrum Master/Product Owner should be aligned across all the squad and share the progress with each other. This will help in creating synergy across the team and things do not miss between the cracks. Discovery server and interface points should be defined and followed religiously. There must be ownership defined for End to End flow: As many times squad just focuses on their own service and its ownership which leads to losing sight of complete flow. Having E2E ownership defined will help in bringing the house in order. Slight reshuffling across the squad is required so that it brings common best practices and standards across the team. This is the part to be done very carefully without disturbing team's bond and ownership. Do post your thought on what are the challenges you guys are facing while implementing Microservices architecture. Also published at https://medium.com/@ashu9719/how-not-to-make-the-microservices-based-project-a-mess-practical-guide-14584bb328c2
