Hacker News Reader

Comment by kolpa | Hacker News Reader

> 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.

View on HN

To 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".

What is that called, then? Having small programs, each responding to a different part of the API, all storing data in a single shared DB?

(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.

I think you are exactly right. Microservice architectures are definitely not automatically good, and there is nothing wrong with a well architected "monolith".

It's called: a distributed monolith

Distributed Monolith

If 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.

That 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.

This is another way of saying that micro-services are for easy problems, where you can avoid having many processes share the same complex database.

It'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).

like all those simple airline reservation and banking systems?

Yes, 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.

Isn't that a feature of old systems in general?

I 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.

Not to mention the endless fun that can be had when one service changes the database schema without telling the others!

It'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

Nah, 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.

Between “database servers” and “database tables” there is another level of granularity: “database users”.

While 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.

Agreed. 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.

If 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.

Separating by schema would work, too. At least, they would be separated from each other but still on the same database.

Reply on news.ycombinator.com