The microservices tradeoffs are very real, not just technically but also organizationally.
If you are developing within a microservices architecture, what are some gotchas and other tips for working day-to-day with this design that others should know?
Top comments (3)
Something we partly rely on is a services working group or guild. This helps, to some degree, with general awareness across teams who are often busy working within their own "domain". Having that consistent visibility helps better understand who does what and what services do what.
Good to know the 23 design principles, distributed systems architecture and resilient design. Some bit of knowledge about deployment.
This may cause some stirs, but I have found an extremely small amount of shared code between services to be a huge help.
I tend to use an EventBus for almost all of my inter-service communications (I'm writing an article on this right now). Having a shared 'EventContracts' library that contains a set of interfaces for implementing a certain event has saved me a lot of headaches when it comes to communication.
I sway between one 'Shared' library that all services use to each service having it's own 'Contracts' library. I switch based on the size/complexity of the project.