The costs of microservices (2020) • Hacker News Board

Re: The costs of microservices (2020)

#171

Post by insanitybit » Mon, Oct 30, 2023, 5:34 PM UTC

nevinera wrote: post #134

insanitybit wrote: post #91

Earlier quoted context omitted.

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no custom…

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude to…

You have no idea what my attitude towards code-review is.

Re: The costs of microservices (2020)

#172

Post by _a_a_a_ » Mon, Oct 30, 2023, 5:36 PM UTC

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…

Word. BTDT, all services getting out of sync etc. Not worth it.

Re: The costs of microservices (2020)

#173

Post by foobiekr » Mon, Oct 30, 2023, 5:37 PM UTC

voxic11 wrote: post #76

eterevsky wrote: post #58

Earlier quoted context omitted.

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

You’re not wrong here but usually this comes down to having one or a small number of version specific container processors (and I do not mean container in the docker sense) to host those functions. Not microservices.

That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance.

I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.

Re: The costs of microservices (2020)

#174

Post by nevinera » Mon, Oct 30, 2023, 5:38 PM UTC

danielovichdk wrote: post #167

nevinera wrote: post #112

Earlier quoted context omitted.

> Can you explain the salient distinction between a "technical" versus "architectural" solution? Candidly, I'm not convinced that there is one. Not concisely in the general case, but in this case the difference is fairly straightforward - CI/CD doesn't affect the structure of your executing application at all, only the surrounding context. I don't want to spend the hours it would take to characterize architecture as…

Which is exactly why the real challenges around (micro) services is to a large extent an organisational challenge mixed how those boundaries are belonging to which business capabilities. The technical part of services is easy enough really but if the organisation leaks its boundaries, which always flow downstream into the actual teams, you are proper fucked. It takes a different level of maturity, both in organisatio…

Right! What I'm fundamentally saying is that the majority of orgs trying to adopt SOA are doing it for the wrong reasons, and will deeply regret it. In general, the "right way" to adopt SOA is to extract services one at a time because you have to, to solve various problems you've encountered (scaling problems, technical problems, stability issues), and then realize that you are in fact currently using a service-oriented architecture, and have been for several years.

Re: The costs of microservices (2020)

#175

Post by mvdtnz » Mon, Oct 30, 2023, 5:39 PM UTC

insanitybit wrote: post #26

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…

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

No, not at all. CI/CD blocking pull requests is in place because large systems have large test suites and challenging dependencies which mean that individual developers literally can't run every test on their local machine and can often break things without realising it. It's not about organisational discipline, it's about ensuring correctness.

Re: The costs of microservices (2020)

#176

Post by nevinera » Mon, Oct 30, 2023, 5:40 PM UTC

withinboredom wrote: post #164

nevinera wrote: post #134

Earlier quoted context omitted.

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude to…

We did post-merge code reviews. But half our team was on the other side of the planet from the other half (4 people on the team, US, EU. APAC, and AU). If we waited for reviews before merging, we’d be waiting weeks to merge a single PR. Thus, you wrote your code, opened a PR, did a self-review, then deployed it. We had millions of customers, downtime was a real possibility. So you’d watch metrics and revert if anythi…

That process sounds fine to me, especially in a context with either good integration coverage or low downtime cost.

> to “ream” someone for merging without deploying is incredibly immature and uncreative.

I'd agree, but I _highly_ doubt that description was an accurate one. Read through the other comments by the same person and you'll get a picture of their personality pretty quickly.

It's likely that there was already an ongoing conflict either in general or specifically between them about this issue. They probably got a moderately harsh comment to the effect of "hey, you're expected to wait for code-reviews now, knock it off"

Re: The costs of microservices (2020)

#177

Post by foobiekr » Mon, Oct 30, 2023, 5:42 PM UTC

elzbardico wrote: post #113

vrosas wrote: post #40

Earlier quoted context omitted.

The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...

Really man. I have almost two decades developing software and yet, I feel a lot more comfortable having all my code reviewed. If anything I get annoyed by junior developers in my team when they just rub-stamp my PRs because supposedly I am this super senior guy that can't err. Code Reviews are supposed to give you peace of mind, not being a hassle. During all this time, I've seen plenty of "small changes" having comp…

At 30 years of coding professionally in great engineering-focused organizations, and that on top of nearly a lifetime of having coded for myself, I’ve concluded code reviews barely work.

I agree with everything you say here, but honestly it’s quite ineffective. I wish we had found something better than unit tests (often misleading and fragile) and the ability of a qualified reviewer to maintain attention and context that a real review entails.

Re: The costs of microservices (2020)

#178

Post by bcrosby95 » Mon, Oct 30, 2023, 5:46 PM UTC

jeffbee wrote: post #9

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 find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example…

Can you point to a comment on HN saying microservices are never justified?

Re: The costs of microservices (2020)

#179

Post by [deleted] » Mon, Oct 30, 2023, 5:46 PM UTC

insanitybit wrote: post #171

nevinera wrote: post #134

Earlier quoted context omitted.

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude to…

You have no idea what my attitude towards code-review is.

[deleted]

Re: The costs of microservices (2020)

#180

Post by bluGill » Mon, Oct 30, 2023, 5:48 PM UTC

mvdtnz wrote: post #175

insanitybit wrote: post #26

Earlier quoted context omitted.

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

No, not at all. CI/CD blocking pull requests is in place because large systems have large test suites and challenging dependencies which mean that individual developers literally can't run every test on their local machine and can often break things without realising it. It's not about organisational discipline, it's about ensuring correctness.

I can run every test on my machine if I want. It would be a manual effort, but wouldn't be hard to automate if I cared to try. However it would take about 5 days to finish. It isn't worth it when such tests rarely fail - the CI system just spin them off to many AWS nodes and if something fails then run just that test locally and I get results in a few hours (some of the tests are end to end integration that need more than half an hour).

Like any good test system I have a large suite of "unit" tests that run quick that I run locally before committing code - it takes a few minutes to get high code coverage if you care about that metric. Even then I just run the tests for x86-64, if they fail on arm that is something for my CI system to figure out for me.