Comment by xyzzy123 | Hacker News Reader

Comment by xyzzy123 | Hacker News Reader

My observation is that much of industry does not care about any of these technical or security issues.

In theory microservices are technical artifacts, but what they tend to be are cultural artifacts.

Microservice adoption is often driven by cargo culting, or (better) a considered decision to work around a lack of organisational cohesion.

What microservices let you do is ship your org chart directly, and also map back from some functionality to an owning team. You know who to page when there's a problem and it's easier to tell who is late delivering and whose code is slow. In cultures with "lax" technical leadership (aka no everyone uses same thing mandate, I'm not judging) it lets teams use their favourite tools, for better or worse.

Other org related things are the ability to have independent (per team) release schedules. Separable billing. Ability to get metrics on performance, cost and failures that can be used as indicators of team performance and promotion material. Microservices can also act as "firewalls", limiting the impact a bad hire or team can have across your codebase.

None of this is intended to be negative judgement; microservices can (among other things), help teams feel a sense of agency and ownership that can be hard to maintain as org size scales up.

Yes. Conway’s law is socially inevitable, align with it. Hari Seldon approves this message.

NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else.

NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else.

Problem is that SOA has been around for decades whereas “microservices” sounds hip and cutting-edge

I think the SOA/microservices distinction has to do with the patterns of architecture more than anything else. (For example, the enterprise service bus is... well, ignore that if you squint it looks a bit like the service mesh and Kafka in a sufficiently complex microservice system.)

There’s no distinction anymore , just like DevOps is now a role not a movement, and hacker is a criminal not a maker. You can’t fight the natural language evolution when it’s buzzwords that people get hired on.

> “microservices” sounds hip and cutting-edge

Maybe 8 years ago it did.

I was definitely contemplating the definition of microservices back in 2012. I think Netflix had been blogging about it then, or just before.

> NB: one may also just call them “services” with no practical loss of generality and sounding less like technobabble to everyone else.

This is completely untrue, and I think it's part of the problem with discussions about microservices. People think it means "lots of small services". That is not what it means. That would be closer to SOA. Microservices is not SOA, and it is not "technobabble".

It has defined constructs, methodologies, and patterns.

You're arguing that the majority of people use the term differently than you and are therefore wrong. Sounds like the definition of technobabble to me.

I think that tech has this extreme, albeit well-earn, revulsion to hype that makes them reject things based on terminology and community over actually understanding the thing.

I see it all the time. It's simply wrong to say that microservices is just "services". Many people being wrong changes nothing.

What _are_ microservices? </DavidDuchovny>

Then what is the difference?

https://www.oreilly.com/content/a-quick-and-simple-definitio...

I feel like you could just google SOA and Microservice architecture, pick up a book, and answer that for yourself.

> People think it means "lots of small services". That is not what it means.

Your link:

> Sam Newman provides a succinct definition of microservices in Building Microservices: “Microservices are small, autonomous services that work together.”

Yeah, this is what I see over and over again. Cherry picking to support bias.

You're the one making a claim that there's a difference, then offering a page that doesn't mention SOA as evidence. So 1) it's your responsibility to prove your own case, and 2) if you just googled SOA and microservice architecture and came up with that page, the strategy you're suggesting has failed.

Yes, I said that microservice architecture has distinct patterns and methodologies. I leave it to you, reader, to discover them.

> Microservices is not SOA

This is not true at all. Microservices are a Service-oriented Architecture:

From section 2.3 in "Microservices: yesterday, today, and tomorrow"

" Microservices are the second iteration on the concept of SOA and SOC."

https://arxiv.org/pdf/1606.04036v1.pdf

There's probably other links I could dig up to prove the point, but I think that one's good enough.

Of course they're related.

> Microservices is not SOA

The earliest things on microservices seemed to be identical to early SOA stripped of lore, usually of specific-context origin, it had accumulated in a decontextualized way, and which was often, especially once decontextualized, not particularly in-line with the original principles.

It's now gone on and attracted a whole bunch more of its own lore the same way, arising out of somewhat different contexts.

And this is a real killer w.r.t. startups adopting microservices: if you're shipping your org chart, but your org chart needs to change frequently to adapt to different contexts as you pivot, arrange, create and eject use cases, microservices cause frequent friction because the relationship between the way you want to organize, and the way the boundaries are established in code, are so different.

I even see the reverse happening, org chart changes made based on service boundaries, due to this friction.

Is this really a problem though? Departments, shifts, brigades have been organized based on plant layout, machines, manufacturing lines, mine shafts, routes, regions and so on for ages.

Microservices or not, above a certain headcount there's no escaping this reality, there's an overhead due to communication, organization, etc. As long as the throughput is greater this way (than without organization, or without the increased headcount) it makes sense to do it.

> You know who to page when there's a problem ..

I don't believe that's true in practice.

Having many services moves a lot of complexity from 1 program to "the system" as a whole. All the stuff outside the services themselves.

Who do you call when the incoming requests are failing, but each service is working fine in isolation?

Further, I think microservices can encourages devs to stay in their own little walled garden and they're quick to say "everything's working on my end, must be somebody else's problem".

Very few people, if any, have a complete understanding of the system and this is often by design which may not necessarily be a good thing. Reasoning between microservices feels harder to me than reasoning within a monolith.

You call your resident "cloud team" or "infrastructure team" for help. Unfortunately, those guys are busy having an existential crisis looking into the abyss of machines, queues, cache layers and databases that are supposedly enabling "smooth team based development".

So you get adventurous and open up XRay or Application Insights or whatever the fuck. After a few hours you realize that the erroneous response code that you thought was the culprit is there by "by design" "intentionally".

So you say fuck it and add another microservice or cache layer that "fixes" the problem and call it a day. You can hear screams of agony from the infrastructure team, but who cares.

When you leave for the day, the boss pats you on the shoulder. "Nice work today, handling that incident", he says.

Isn't the only thing here that is enabled by microservices the separate tooling part? Couldn't the rest of it be achieved somewhat easier with a standard service-oriented architecture in a monolith? Why do we need to insert network calls between everything?

It allows different teams to write in different languages, have different deployment cadences and different testing mechanisms.

The overhead of network calls and its attendant problems can be a worthwhile price to pay if you need to loosely couple your teams.

This is why my yardstick of "should it be a micro service?" is "could it work as an entirely separate business?"

I was a massive skeptic of micro services until I saw that it actually solved some people problems pretty well despite incurring a technical cost.

I'm pretty convinced it's an anti pattern in small startups though.

I believe network calls are a looser contract than function calls that would be checked at compile time, so it allows a softer decoupling between multiple teams. Compatibility or intermittent failures are handled with different strategies (rollout, rollback, deadletter queues) instead of impacting release cycles.

They can do exactly the same when shipping libraries into the company's central library repository, NuGET, Maven, Gems, Eggs, whatever.

Reply on news.ycombinator.com