Every microservice, exposes APIs. I've read somewhere that, it's a bad practice to export an SDK to other microservices because it limits the independent deployability. But is it true? What are other downsides of this approach?
The problem is that, without the SDK, every microservice will need to request the same data, and validate it in some way - which is some boilerplate code which in general one would like to have automatically filled.
You don't share code between the services, services call each other. This mean you will have some code that is duplicated between services, that's normal.<p>One microservice should never directly modify data another microservice manges, each service should manage and maintain its own data source to keep the responsibilities clear.<p>There are some other methods for certain common functionality, like using sidecars etc. There are pros and cons of it all, just depends on the situation and beliefs of the architect.<p>IME, most companies aren't ready for, nor do they need, a true full scale microservices architecture. Instead a hybrid approach is more likely to be successful, where certain key services are isolated but the rest of the app can still be more of a monolith. The trick is identifying those key services and separating them out. One I almost always separate as a start is authentication/authorization, done properly it will keep that code very focused, clean and more secure. Other likely candidates are any service that might ingest large amounts of data but is focused, this will let you scale it independently to support load and growth but not force you into a complete microservices environment which can be daunting to manage at first.