Hacker News Reader

Comment by gregmac | Hacker News Reader

I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently.

One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema is now also a crappy API).

As soon as you start having concurrent deployment dependencies -- that is, the updates for service a + b both have to be deployed at the same time or things are broken -- you've effectively built a monolith anyway, just with an annoying code layout (eg, spread across multiple repositories).

You can use orchestration to tie these deployments together, but this means you're effectively building a monolith with a microservice architecture. Is that really what you want?

View on HN

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.

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

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

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.

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

> this means you're effectively building a monolith with a microservice architecture. Is that really what you want?

I actually kinda do want that, although maybe it's a niche thing.

It would be nice to be able to deploy a monolith that's already cut at seams where there's an obvious API boundary. At one extreme, you could imagine a single binary where processes communicate via RPC.

What that would give you is an easy way to split off microservices as they're needed.

I'm sure somebody has done work along these lines.

This is actually a similar approach to how next.js deployed to vercel (previously zeit) works by default. Each page or api endpoint is served by an individual lambda function so they can scale up or down independently

https://nextjs.org/docs/deployment#optimized-for-nextjs

Awesome thank you

Reply on news.ycombinator.com