3 ms·
Think of a situation where you have, for example, a database like Redis. If you need to run two systems that need to access that data there will need to be some
by gravypod 5y ago
Think of a situation where you have, for example, a database like Redis. If you need to run two systems that need to access that data there will need to be some process that maintains that data and allows other people to access it.
You would have a hard time to make a resource efficient distributed in-process key-value store.
You could have an in-process library but this would cause your two programs to have either:
1. Store different data
2. All writes would need to be distributed to all processes (looping back to needing a network connection).
- anyfoo 5y agoYeah, that makes sense for the data store, but don't microservices split up much more? Of course this could quickly devolve into a conversation about "at what point is it microservices".
- gravypod 5y ago> Of course this could quickly devolve into a conversation about "at what point is it microservices". Yep, exactly. I've built more than one microservice in my time that loads up a few GB of data into RAM and efficiently queries it for a lot of services. At that point the line between DB and service gets blurry. But, essentially, the TCP connection between your services isn't necessarily a big issue. If there is some logic/operation/access that is complex it makes sense to chuck a language-independent interface in front of it for most use cases. There are some where performance trumps maintenance but where it doesn't I think this abstraction is helpful.