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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

291–300 of 410 posts

Re: The costs of microservices (2020)

#291

Post by smrtinsert »

nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

I've always thought of this as the best example of deferred execution. It's surprising how often businesses get it wrong. I think the problem is most "good" workers are over eager to demonstrate value. They do that by over engineering and that leads to hell etc...

Re: The costs of microservices (2020)

#292

Post by LelouBil »

superfrank wrote: post #203
bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…

In the department I work there's a lot of microservices, about 5-6 so 5-6 teams. But everything is quarkus/spring java and nothing else.

Re: The costs of microservices (2020)

#293

Post by ysleepy »

highspeedbus wrote: post #215

Monoliths are like heavy trucks. Microservices are like motorcycles. Surely you can delivery 15 metric tons of wood with either of them. You will just need a lot of motorcycles to match capacity. Somehow a big part of industry became convinced that of course that approach is better, since motorcycles are cheaper*, easier to scale*, and solve some managerial problems*. * They don't, IMHO. >its components become increa…

Was with you until you mentioned Robert Martin. I have no respect for that shill.

Re: The costs of microservices (2020)

#294

Post by LelouBil »

tcgv wrote: post #270
superfrank wrote: post #203

Earlier quoted context omitted.

I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…

> Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. This works well if you have knowledge redundancy in your organization, i.e., multiple teams that are experienced in each programming language. This way, if one or more developers experienced in language 'A' quit, you can easi…

> More often than not, the choice between Microservices and Monoliths is more of a business decision than a technical one to make.

I think that, technically you can use one or the other and make it work. However management is very different in the two cases, so I completely agree with you. I hadn't thought of the part about moving people between teams.

It's my first job but I understand why they chose microservices : 6 teams working on 6 "features/apps" can be managed (almost) fully independently of each other if you split your code base.

Re: The costs of microservices (2020)

#295

Post by LelouBil »

lemmsjid wrote: post #223
cpill wrote: post #205

Earlier quoted context omitted.

> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…

If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases. There are well known design issues in mo…

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

Re: The costs of microservices (2020)

#296

Post by sanderjd »

starttoaster wrote: post #222
bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…

> you just need to know each juncture where that strand weaves into other strands.

No I don't, that's what computers are for. It's why static analysis is good. Instead of knowing what calls what, you say, "yo, static analysis tool, what calls this?".

Re: The costs of microservices (2020)

#298

Post by Thaxll »

bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

Why did you have 2-3 languages, does not make sense, I've been using microservice for a while and it was only one language at a time.

Re: The costs of microservices (2020)

#299

Post by BHSPitMonkey »

sanderjd wrote: post #296
starttoaster wrote: post #222

Earlier quoted context omitted.

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…

> you just need to know each juncture where that strand weaves into other strands. No I don't, that's what computers are for. It's why static analysis is good. Instead of knowing what calls what, you say, "yo, static analysis tool, what calls this?".

The comment you quoted is talking about the non-monolithic situations where static analysis tools cannot help you, e.g. when the callers are external and difficult to trace.

Re: The costs of microservices (2020)

#300

Post by lmm »

bob1029 wrote: post #197
tsss wrote: post #185

Earlier quoted context omitted.

No one says you can't have all of your microservices use the same language...

Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood…

Does .net not have a way to run simple private repository like Nexus? Over in JVM-land that's a basic thing that you'd be doing anyway.
Post reply on HN