And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql
Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.
Is this a joke or people seriously do this?
It's industry best practice -- not a joke. What's more, the recommendation is to have a separate database per service -- one table, one service, one database.
Fuethermore, when a join is desired, the best practice is to implement not just a service that joins the data but maintains it in a table/materialized view of its own, along with a message server such as Kafka. The services responsible for the tables to be joined (customers and orders, for instance) put events on this message bus which the joining service subscribes to in order to know when to update its view. See: https://microservices.io/patterns/data/cqrs.html
And don't get me started on how you do transactions that touch multiple tables in this setup: https://microservices.io/patterns/data/saga.html
I have seen these deployed and advocated as the modern way to write business applications in the wild.
There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services.
No, I'm not kidding. This is literally what people do and recommend.