paint-brush
How to Ensure the Success of Microservices-based Projects by@ashish-singh
315 reads
315 reads

How to Ensure the Success of Microservices-based Projects

by Ashish SinghDecember 30th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Microservices-based projects are a great idea to deliver products in less time and with great flexibility/agility. The major ways microservices projects help in quick deliveries are: Dividing the work into different services. Assigning the services to each squad to work independently does not mean making themselves isolated from the bigger picture of business flow. End to End (E2E) testing should be independent of services squad. Discovery server and interface points should be defined and followed religiously. Permission hierarchy most important thing is to have the right cut/ boundary for the services.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - How to Ensure the Success of Microservices-based Projects
Ashish Singh HackerNoon profile picture
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:
  1. Dividing the work into different services.
  2. Assigning the services to each squad to work independently: Parallelism of work
  3. 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:
  1. Datastore/ DataLake
  2. State of process
  3. Permission hierarchy
  4. 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

바카라사이트 바카라사이트 온라인바카라