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

Microservices

basho.com

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Microservices

#111

Post by robotresearcher »

anamexis wrote: post #107
robotresearcher wrote: post #30

Earlier quoted context omitted.

Multiple instances with shared nothing is the opposite of a monolith, by definition.

Not if they're all running the same code.

OK, I looked up the definition of monolithic application in a couple of places, and the meaning is not quite what I thought it was. I thought it was 'one app does everything for everybody' but it's more like 'one app does everything for somebody', so the horizontal scaling applies, and my previous comment is wrong.

It's a shame that a 'monolith' application doesn't just mean a genuine singleton, though, as that would be the perfect name for it. A bank of load-balanced monoliths should be a polylith.

Re: Microservices

#112

Post by rdsubhas »

michaelcampbell wrote: post #100
rdsubhas wrote: post #48

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

This looks like almost a direct copy of one of Matt Stine's popular talks.

I'm sorry I'm not aware of the person, but would be interested in reading/seeing it. A quick google search yielded https://blog.pivotal.io/pivotal-perspectives/features/revisi... - Is this the one you referred?

Btw - the list is not an invention worth copying. All items in that are not novel or unique, they are general practices that every good engineer would have their own version of. I'd like to see the talk and try to add a few more items to this.

Re: Microservices

#113

Post by _pmf_ »

throwaway13337 wrote: post #15

Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…

> It just so happens that the portion of the community is the one most looked up to by the rest of the community

It certainly is the most vocal.

Re: Microservices

#114

Post by mahyarm »

eternalban wrote: post #97
mahyarm wrote: post #95

You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. It allows teams to work in their own world without having to coordinate as much with other teams or people. Microservices are good for large companies. If you're small you don't need them.

> You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. A layered architecture can give you the same. Microservices, imo, address organizational/industry deficiencies in the design and evolution of domain models. You're basically trading analytical pain for operational pain. As the top comment in this thread (with the excellent list) concludes, you will nee…

Microservices also enforce boundaries significantly more strongly. A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system.

Large companies don't have problems throwing more engineers at a problem. But they will always have a problem in coordination costs.

Microservices also allow you to use different tech stacks for different purposes more easily.

Maybe use java for one involving hadoop or some GIS library. Use erlang for some message management service, use golang for some simple API service, use nodejs for some frontend web server, etc.

Overall the advantages of microservices come for social reasons, not for a particular technical reason.

Re: Microservices

#115

Post by romanovcode »

pbreit wrote: post #41
throwaway13337 wrote: post #15

Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…

My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Djan…

Tell me about it. Exactly same situation here. You forgot the fact that they're paying 1k+ for AWS for all these services where if it was a normal application it would've cost around 100 bucks.

Re: Microservices

#116

Post by romanovcode »

ryan-allen wrote: post #106
pbreit wrote: post #41

Earlier quoted context omitted.

My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Djan…

The app I'm working on is an ASP.NET MVC monolith, and it's fantastic. Yeah it's not new fun tooling, but boy does it feel good to ship features without it being a total pain in the arse. Also C# is pretty nice.

Well if you migrate to .NET Core (MVC) aka MVC6 it will be new fun tooling.

Re: Microservices

#117

Post by TickleSteve »

dragonwriter wrote: post #73
TickleSteve wrote: post #68

“You don’t need to introduce a network boundary as an excuse to write better code” Absolutely this! microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. Monolithic code can also be nicely decoupled too.

> microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. If code is decoupled enough that it can be separated into independent processes communicating over a network, that creates additional freedom into how the components can be deployed to (real or virtual) hardware, which is itself a kind of decoupling. If you have processes communicating by local-only IPC meth…

disagree,

coupling is a logical connection, and has nothing to do with calling-semantics.

Whether a local function call or an RPC, its still the same level of coupling, this is just a difference in the (equivalent of) a link-layer in a network stack.

Adding a network connection is a much more complicated calling-semantic than a function call, many more and different failure modes.

Re: Microservices

#118

Post by tkyjonathan »

rdsubhas wrote: post #48

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

You can add to your list all the sysadmin, devops complexity to the power of two, new single-point-of-failure issues, SLAs, backups, retention of backups.... Basically, you are multiplying the complexity of the ops people.

Re: Microservices

#119

Post by crdoconnor »

rdsubhas wrote: post #48

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

They're nearly always a major violation of KISS, in other words.

Re: Microservices

#120

Post by cmdkeen »

StavrosK wrote: post #90
rdsubhas wrote: post #48

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

That's pretty spot on. I once made an abbreviated flowchart of the above for my microservices article: https://www.stavros.io/posts/microservices-cargo-cult/ I urge everyone to use it to decide whether they really need microservices or not.

I know it is a bit tongue in cheek but if you're working somewhere where Data Segregation can be solved by "a simple cascading delete" you aren't operating anywhere close to where any service architecture is relevant.
Post reply on HN