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

What Even Are Microservices?

var0.xyz

Post reply on HN
Print view View original

51–60 of 87 posts

Re: What Even Are Microservices?

#51

Post by regularfry »

roncesvalles wrote: post #28
turnersauce wrote: post #11

This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries. https://en.wikipedia.org/wiki/Conway%27s_law

Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time. It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction. I don't agree that there are organizational causes even though that's…

One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.

Re: What Even Are Microservices?

#52

Post by aleksiy123 »

kgeist wrote: post #33

In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems) There are two things monoliths can't easily offer: * Using different frameworks,…

Data isolation, separate auth/permissions/roles, Compliance, crash isolation, Resource/capacity management

There’s probably more off the top of my head. Not that I necessarily advocate for the micro in services. Just the sliding scale of macro-micro services.

These are more problems in larger companies.

Re: What Even Are Microservices?

#53

Post by regularfry »

asimpletune wrote: post #37

This is what people always say but it's not really the only case, and it's not even a particularly good case. You could achieve the same organizational thing through modules, for example. The real—and the one thing you can't replicate—is data isolation. Of course there are other benefits, but it's data isolation is the differentiator of micro-services and other types of architecture.

It's not just the modular organisation that you've got to get right though, although that's definitely a big thing. Deployment independence matters too: if I've got a perfectly modular monolith but I have to coordinate with everyone else who lives in that monolith to get my module into production, it's leaving half the gains on the table.

Re: What Even Are Microservices?

#54

Post by sdfdfsfsdsdf »

anymouse123456 wrote: post #31

[flagged]

I have a team that doesn't communicate well and is generally dysfunctional in all ways imaginable.

Microservices isolate them quite literally and lets them work in peace and quiet.

The system as a whole is completely batshit crazy of course, but for some teams, this can turn an unworkable situation into "we might survive this" which is when push comes to shove all that matters.

Re: What Even Are Microservices?

#55

Post by mrkeen »

inigyou wrote: post #46
reactordev wrote: post #18

Earlier quoted context omitted.

This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.

Why do you think different people can't work on different parts of a single deployment unit (which is what we mean by "monolith")?

* My last monolith job had 4 hour release windows.

* You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical.

Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't have to waste any time worrying or arguing, since him keeping the system as a monolith made this change impossible.

Re: What Even Are Microservices?

#57

Post by regularfry »

figmert wrote: post #26
turnersauce wrote: post #11

This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries. https://en.wikipedia.org/wiki/Conway%27s_law

Yes, and then they start complaining that the shared domain objects are not kept up to date by team $notMine, and so they inevitably go to a shared library where they fall back into the same issues.

If you're needing to share code for domain objects between microservices something has gone badly wrong.

Re: What Even Are Microservices?

#58

Post by zero_shift »

reactordev wrote: post #43
zero_shift wrote: post #35

Earlier quoted context omitted.

Tracing and o11y are a poor sibling to static analysis. > This is complete lack of experience on the authors part Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system The range of what a program can do is much larger than what a program does do in your two w…

It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.

Observability and operability are just not the same thing as being able to reason about the software. You need both

You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness

Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell

There will be code paths that have never been triggered that you still need to reason about as part of analysing a system, eg in threat modelling

> I get why you think I might not have worked on large systems

I didn't, necessarily. But it looked like an excessively strong claim, combined with a challenge to the author's competence. I wanted to call that out.

Re: What Even Are Microservices?

#59

Post by grim_io »

Imagine you're a unicorn startup, you just hired 1000 devs in the last 2 months.

It turns out, every team thinks they got the smartest people, and they all hate the idea of collaborating with the inferior teams.

Yeah, you will need microservices to bandaid your dysfunctional org. You'll keep going, slowly.

Literally the only reason I can imagine for microservices.

Re: What Even Are Microservices?

#60

Post by marginalia_nu »

kgeist wrote: post #33

In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems) There are two things monoliths can't easily offer: * Using different frameworks,…

Concerns that shape my own decision to run Marginalia Search as a service based architecture rather than one blob include:

* NUMA optimization - on multi-CPU architectures, I/O and/or memory bottlenecked software takes a pretty significant performance hit if you let is run on both CPUs, and this has knock on effects that also degrade the performance of other software running on the same machine.

* Network namespaces - if you're e.g. running an internet crawler, and want to assign one host machine multiple public IP addresses, this is much easier if you use something like ipvlan.

* Stateful long running process lifecycles (e.g. crawling) that coexist with the need for live redeployments of other parts of the system.

Post reply on HN