Microservices: when to choose it, how to migrate painlessly, & make it resilient

Arpit Mohan - Nov 20 '19 - - Dev Community

TL;DR style notes from articles I read today.

Musings on software architecture: monoliths to microservices


  • Microservices architecture adds huge complexity overheads on your infrastructure & may not be suitable for a new project from the start.
  • As a developer, you take on a lot of communication and coordination in addition to coding.
  • Even successful companies using microservices today started as monoliths.
  • When you start with a single team and a single product, it is logical to continue with a monolithic application.
  • Later, teams can split to be responsible for single services. Microservices may make better sense after that growth and when necessary experience and expertise is gained.


Full post here, 4 mins read


9 tips for a painless microservices migration

  • Draw domain lines to define and document your business entities early on. Be mindful of how you cross the boundaries between these entities.
  • Document your URL route domains and ensure everyone follows the one convention.
  • Be explicit about routes and methods. Avoid wildcard routes and wildcard verbs or HTTP methods.
  • Assign URL endpoint ownership for clean formation of teams in the future.
  • Monitor URL usage by instrumenting the endpoints - at least graph the request rate, if not the error rate and performance of every HTTP endpoint you expose.
  • Kill dead code - delete it, not just comment on it. Have source code control for history, if needed.
  • Document the environment variables a service, class or module uses. 

Full post here, 8 mins read


3 easy things to do to make your microservices more resilient

  • Test your system using chaos strategies.
  • Have a plan to at least partially fulfill your service promise in case of a fault, whether it is a canned message or calling a different service as a backup.
  • Be conservative in what you send to a service and liberal in what you accept. Your unmarshalling logic should do just enough validation of responses and pull out just the data you need rather than executing a full validation.
  • When services fail, multiple iterations of the same message should not add inconsistencies to your users’ systems.
  • Use infrastructure that filters out duplicates. Or, track unique identifiers in the messages and discard those that are already processed successfully. 


Full post here, 7 mins read


Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player