9 ms·
> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But
by kolpa 8y ago
> Usually microservices have their own databases
That's news to me, and seems insane.
Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.
- VBprogrammer 8y agoThat architecture is commonly known as a distributed monolith. If you put two services on the same DB you can guarantee that someone will be joining onto a table they shouldn't have before the week is out.
- ljw1001 8y agoThis is another way of saying that micro-services are for easy problems, where you can avoid having many processes share the same complex database.
- wsy 8y agoIt's exactly the other way around: If you can afford all your components sharing the same database without creating a big dependency hell, then your problem is _too small_ for microservices. If your problem is so large that you have to split it up to manage its complexity, start considering microservices (it might still not be the right option for you).
- ljw1001 8y agolike all those simple airline reservation and banking systems?
- wsy 8y agoYes, they do fine as examples. I have worked both on decades old booking systems and banking software. Both were dependency hells. Refactoring was impossible. Everybody was super-careful even with tiny changes because the risk to break something was just too high. If it could be avoided, these systems were not touched anymore. Instead, other applications where attached to the front and sides.
- collyw 8y agoIsn't that a feature of old systems in general?
- wsy 8y agoI don't think so. For example, the Linux kernel is old, but still quite well maintainable. So I would say: it applies to systems where proper modularization was neglected. In the anecdotical cases I referred to, one major element of this deficiency was a complex database, shared across the whole system.
- WJW 8y agoNot to mention the endless fun that can be had when one service changes the database schema without telling the others!
- jsight 8y agoTo be blunt, its news to a lot of people, but it also isn't wrong. Microservices really shouldn't share a database, and if they do then they aren't "microservices".
- copperx 8y agoWhat is that called, then? Having small programs, each responding to a different part of the API, all storing data in a single shared DB?
- ljw1001 8y ago(a) a prototype (b) a set of applications that share a database. You would have to have an oddly disconnected schema if modifications to the program don't result in programs accessing parts of the database that other programs are already accessing. If this isn't a problem it means you're using your database as nature intended and letting it provide a language-neutral, shared repository with transactional and consistency guarantees. so maybe not microservices, but fine nonetheless. EDIT: two more comments: - this is exactly what relational databases were designed for. If people can't do this with their micro-services, maybe their choice of database is the issue. - "micro-service" as the original post suggests, is not synonymous with good. "monolith" is only synonymous with bad because it got run-over by the hype-train. If you have something that works well, be happy. Most people don't.
- jsight 8y agoI think you are exactly right. Microservice architectures are definitely not automatically good, and there is nothing wrong with a well architected "monolith".
- matrix 8y agoIt's called: a distributed monolith
- Beldur 8y agoDistributed Monolith
- erik_seaberg 8y agoIf you're going to go microservices, you want service A to use service B's public API (MQ or RPC or whatever), not to quietly depend on the schema B happened to choose. And sharing a database server instance turns overloads into cascading failures, unless the stack is very good at enforcing resource limits on noisy neighbors.
- kgwgk 8y agoBetween “database servers” and “database tables” there is another level of granularity: “database users”.
- VBprogrammer 8y agoWhile that's true. It also means you are only one grant away from sharing database tables. Maybe with good discipline you will be ok but all it take is for one dev to take that one shortcut.
- user68858788 8y agoAgreed. I've only seen proper user separation happen when legal gets involved. Usually it's an all-access free-for-all, and after all, why shouldn't it be? It's a lot easier to pull data and logs from adjacent services yourself rather than taking a ticket and hoping the team still exists for a response.
- ahoka 8y agoIf you have different database servers then you are only a "connection string" away from breaking your separation. Using a different login and schema is perfectly fine in a lot of architectures.
- dvlsg 8y agoSeparating by schema would work, too. At least, they would be separated from each other but still on the same database.
- y4mi 8y agoIt's neither new nor insane... Putting everything on the same server becomes a scalability nightmare at some point. This video is strangely relevant in this thread... https://www.youtube.com/watch?v=X0tjziAQfNQ https://www.youtube.com/watch?v=X0tjziAQfNQ
- thermodynthrway 8y agoNah, just use a database that can scale with your app and run a ton of instances. You'll be hard pressed to find any size app that doesn't fit in RAM these days.