Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are hard

code-held.com

Post reply on HN
Print view View original

351–356 of 356 posts

Re: Microservices are hard

#351

Post by hot_gril »

roflyear wrote: post #350
hot_gril wrote: post #313

Earlier quoted context omitted.

> You mentioned RPC's. Your service interface has nothing to do with the data organization. I find data organization to be a direct consequence of service interface. If two things aren't talking over RPCs or pubsub, they're talking through the database. It's not just my org. Pretty common for monoliths to end up with an obscene reliance on a single DB and start looking for a huge machine to support it. There isn't a…

> I find data organization to be a direct consequence of service interface. Then, you will not like microservices. Microservices make it harder, not easier, to organize data. You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources. It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be…

Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith.

BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost.

> the only thing it gives you is that it forces you to silo data

It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.

Re: Microservices are hard

#352

Post by roflyear »

hot_gril wrote: post #351
roflyear wrote: post #350

Earlier quoted context omitted.

> I find data organization to be a direct consequence of service interface. Then, you will not like microservices. Microservices make it harder, not easier, to organize data. You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources. It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be…

Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith. BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just g…

Sure, but likely that team is not working on a single service when people say microservices. That could be SOA, which is more my preference, but definitely not a microservice going by the most popular definition which is "small enough to rewrite."

> BTW, monolith DB has its own form of eventual consistency.

Sure, on very large systems. Microservices always have this - even tiny systems.

> It gives you a smaller blast radius when something goes wrong,

At the cost of often having a much harder time fixing things when they do go wrong :)

> avoids over-stressing a single DB,

Monoliths can use as many databases as they want! And you can use a single DB with a microservice architecture across many microservices (tho I think this is an anti-pattern, teams often do it).

> alleviates single points of human dependency like the DB curator,

I haven't been at a job that has a DB curator, but it compounds the "bob wrote those ten services in rust, who... who knows rust? anyone?" issues :)

> lets you scale separate pieces independently,

You can do this with a monolith with many technologies, though seems easier to do for a microservice as a general rule. But, you have to need that scale first!

> and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.

Plenty of larger orgs also avoid microservices!

Re: Microservices are hard

#353

Post by John23832 »

hot_gril wrote: post #351
roflyear wrote: post #350

Earlier quoted context omitted.

> I find data organization to be a direct consequence of service interface. Then, you will not like microservices. Microservices make it harder, not easier, to organize data. You have to worry about problems such as eventual consistency, and figure out how to join data across multiple data sources. It compounds the problem significantly, and the only thing it gives you is that it forces you to silo data. That can be…

Usually the service structure will mirror the team structure, e.g. one team of 2-6 SWEs per service. I've enjoyed doing things this way now that we're out of the monolith. BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just g…

> BTW, monolith DB has its own form of eventual consistency. Process A puts data into DB, process B picks it up later and affects the DB. There's no reasonable way that everything in such a multi-use DB is always logically in agreement. You're just guaranteeing that B sees what A writes immediately, which comes at a cost

Transactions have existed for years, and DB execution engines have been able to concurrently handle non-dependent transactions since the mid 90's.

> It gives you a smaller blast radius when something goes wrong, avoids over-stressing a single DB, alleviates single points of human dependency like the DB curator, lets you scale separate pieces independently, and yes forces you to silo the data. There are several good reasons larger orgs have been doing things this way for a long time.

Vertical scaling of Db's is a non issue. If your DB is complex, get a DBA...

Have you actually done any of this in production before? It doesn't seem like it honestly.

Re: Microservices are hard

#354

Post by jfoster »

philosopher1234 wrote: post #52
jfoster wrote: post #44

Earlier quoted context omitted.

I would argue the inverse. If you reject both extremes, and are somewhere in the middle, you probably are much closer to something reasonable. (both in engineering and when driving)

Doing the average of everything is a great way to be pretty wrong. If you have to guess, guessing average seems fine, but if you know better, going with the herd can be foolish.

If the herd is at one extreme or the other, the middle ground is the opposite of going with the herd.

It could be unpopular because it's wrong, or it might be the insightful choice. Critical thinking will probably help figure out which it is.

Re: Microservices are hard

#355

Post by turtleyacht »

tetha wrote: post #274
sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

Agreed. I very much like my workplaces approach atm, which I jokingly call medium-sized services, mostly. Due to acquisitions, we have 6 or 7 big messy monoliths and actually, 3-5 infrastructure stacks. This in turn means, we have something like 12 different user management systems (because each monolith contains a few layers of legacy user management, it'd be boring otherwise), 4-5 different file and image stores (s…

From your advantages:

> smaller service... extremely critical... manage... gently

> reduce redundant efforts

Versus

> dedicated SAML-integration-spring-app

What if the effort were spent automating the disparate systems to stay in sync?

Granted, the data model reflects multiple systems, but each user could use their preferred "set of apps," and changes get reflected by some headless Windows container or browser.

Re: Microservices are hard

#356

Post by [deleted] »

gen220 wrote: post #289
philote wrote: post #260

Earlier quoted context omitted.

Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services, and have a repo for each service. Otherwise, you're deploying code changes for one service that could, in theory, mess with another service that you don't maintain.

In a phrase, it's having a single "bleeding edge" for the entire company, vs 1 bleeding edge per service. Some benefits of this include: You have one commit hash in one repo that tells you what version service/consumer X is expecting / providing. If you want to understand why a service isn't working as expected, it's trivial to grep its implementation and contribute solutions. As a service owner, you can grep for all…

[deleted]
Post reply on HN