3 ms·
It's mostly about data. Each micro services is responsible for their own data, data migrations, data store, etc. Think of it as a mini web app with an API. In t
by olalonde 4y ago
It's mostly about data. Each micro services is responsible for their own data, data migrations, data store, etc. Think of it as a mini web app with an API. In theory, you could use a library in that way but I have never seen such use in practice. You would also run into the problem of having to always keep all library users on the latest version as to avoid having two versions which expect different database schemas. It also largely forces you to stick to a single programming language.
- quickthrower2 4y agoConversely though, if you can make do with a single data store and data layer (orm or just simple queries) the libraries can use that. The schema and generated classes could be a shared common library that different teams can work on (maybe with some architecture obersight) Or if using schema-less each library “knows” it’s own json formats Then you get nice things like atomic transactions across multiple “services”. You also have no network concerns. You can pull out microservices for things that need special attention. Such as a spikey-load service that might need to run as a lambda. Version management is a solved problem. Use your languages package manager and semantic versions. I concede you need to stick to one language. Ish. You have C FFIs. A .NET app could reference a dll written in C++ or Rust. But yeah not as flexible as services. Although there are inbetween things like RPC.