Live data from Hacker News

What Even Are Microservices?

var0.xyz

21–30 of 87 posts

Re: What Even Are Microservices?

#21
post #6

> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about…

You do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.

Re: What Even Are Microservices?

#23

A "real" microservice (according to some definitions) might be only really necessary for organizational reasons. But the services in a distributed monolith are also often called microservices (at least in my company). And for them I believe there is another good reason that I do not hear about in these discussions: robustness. In our software project, we have had many issues with OOM and golang panics in a goroutine…

> But the services in a distributed monolith are also often called microservices (at least in my company).

I thought that was a "microlith".

Re: What Even Are Microservices?

#24
I feel like the discussion between "monolith" and "microservices" is a false dichotomy.

For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.

You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.

Re: What Even Are Microservices?

#25

Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding. Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.

[dead]

Re: What Even Are Microservices?

#26

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.

Re: What Even Are Microservices?

#27

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

They can serve multiple purpose and that's not the problem, because there's precedent in the literature -- software architecture the hard parts https://www.oreilly.com/library/view/software-architecture-t... -- for teams to organize architecture review cycles and decide if some microservers are better merged into a monolith. This however requires tons of refactor when microservices aren't design with this part of its lifecycle in mind, and we all know how this kind of investment is risky and hard to communicate to non-technical management.

Re: What Even Are Microservices?

#28

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 oft repeated as one of the main reasons. I have never seen a one-to-one relationship of microservices and teams irl. Most teams own many services and some services get touched by many teams. In big companies, there are also microservices with zero owners.

Re: What Even Are Microservices?

#29

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

That's the sane way of using services, but micro-services used in the wild are often used without any organizational consideration at all: as a consultant I witnessed countless of small companies and start-ups who had multiple times more services than developers! (The biggest culprit was the latest one: 61 micro services for 3 devs and a PM, and it wasn't even an outlier) .

What could be a sensible architecture for large orgs has become more of a cult-like behavior that drags everyone down.

Post reply on HN