[dpix]

Sharing databases across services (micro or not) is generally a pretty bad idea exactly for reasons around versioning.

Versioning APIs is a pretty standard way to get around this.

If your deployment relies on synchronized service deployments you really dont have independent services at all.

[danenania]

"Sharing databases across services (micro or not) is generally a pretty bad idea"

I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious overkill, complicating ops and introducing potential data integrity issues for no real benefit.

"If your deployment relies on synchronized service deployments you really dont have independent services at all."

So what? That's really the point: blindly following the Microservices (TM) doctrine is often a mistake. It's better to just solve whatever problem you're facing in the simplest possible way. While that may mean by-the-book microservices with independent databases, in many cases something in between is a better choice.

[dpix]

I didn't mean it as a completely blanket statement, hence why I said "generally". In my experience it's a lot harder to manage a contract between a db schema and multiple codebases over managing versioned contracts between APIs.

"It's better to just solve whatever problem you're facing in the simplest possible way."

I completely agree with this, but I dont beleive that syncronizing deployments across multiple services is ever simple - have been in this situation at a past company where it would take an entire week every 3 months to do a deployment

[danenania]

Fair enough, but I think even "generally" is too strong. There's a huge cost to splitting into multiple dbs, and I'd say it should be avoided by default unless the benefits clearly outweigh the complexity costs. Just to give one example, authentication gets way more difficult with separate dbs, and you get a whole new class of potential security bugs.

Your concerns about versioning and deployments are certainly valid, but I don't think they outweigh the costs of turning your data layer into a distributed system until a project gets very large or those issues are actively causing you headaches.

[folmar]

Writable views or stored procedures are a pretty standard way to versioning database access from clients.