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

131–140 of 152 posts

Re: Microservices

#131

Post by mej10 »

jsmith0295 wrote: post #87
xorcist wrote: post #81

Earlier quoted context omitted.

In many ways it's just like micro kernels again. If micro services are the bee's knees, why are you writing them in Eclipse or Emacs? Wouldn't interconnected processes make up a "better" environment? An why are you deploying on something as monolithic as Linux? Shouldn't you out-compete all of these obviously inferior solutions, as there are probably more money in that than whatever web app you are currently building…

That's one thing I've always thought when people claimed microservices followed "the UNIX philosophy". UNIX doesn't even follow that philosophy, it's a monolith! Yet it's also a modular system, which is possible without being either a microkernel or microservices.

The kernel is only one piece of a *NIX system. The userland tools are (mostly) a good example of small focused applications that can be combined in interesting ways.

Re: Microservices

#132

Post by kwonstant »

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…

Similar situation here. Architect's desire: exposing usage and load metrics to autoscale the services.

Reality: Everything runs on two EC2 instances, regardless of load.

Re: Microservices

#133

Post by berta »

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…

Awesome inventory. I'd add service discovery and distributed key/value store for configuration data

Re: Microservices

#134

Post by Diederich »

phs318u wrote: post #108

I'm a little long in the tooth so aren't as up to date with every new fangled technique to land in IT. Some of you may find this anecdote interesting and somewhat pertinent. Many years ago the electric utility I worked at had a home-grown set of batch-run Pro-C and PL/SQL programs that ran various metrology operations on large volumes of meter data. These things were interdependent, ran single-threaded and created a…

Yes, thank you.

I've done little heavy lifting with Oracle, but the general pattern you describe has been my go-to methodology for north of 20 years now. I've come to call it 'message oriented programming'. But it's just one of many ways to embrace the benefits of loose coupling.

Re: Microservices

#135

Post by jsmith0295 »

mej10 wrote: post #131
jsmith0295 wrote: post #87

Earlier quoted context omitted.

That's one thing I've always thought when people claimed microservices followed "the UNIX philosophy". UNIX doesn't even follow that philosophy, it's a monolith! Yet it's also a modular system, which is possible without being either a microkernel or microservices.

The kernel is only one piece of a *NIX system. The userland tools are (mostly) a good example of small focused applications that can be combined in interesting ways.

Yeah, that is definitely true. I was looking at it as effectively being a monolith that existed to facilitate that, but that does only apply to the kernel.

Re: Microservices

#136

Post by sbov »

robotresearcher wrote: post #111
anamexis wrote: post #107

Earlier quoted context omitted.

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…

I'm not sure if it's a useful distinction, because when you think you're building a 'monolithic' app you might actually be building a 'polylithic' app. Beyond that, in a lot of instances you have to make very few tradeoffs to go from 'monolith' to 'polylith'.

By your definition, most rails/django apps are probably polyliths.

Re: Microservices

#137

Post by eternalban »

mahyarm wrote: post #114
eternalban wrote: post #97

Earlier quoted context omitted.

> 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…

Layered systems do not have to be 'monolithical'. Note that we're both at this moment using layered systems to have this conversation.

> 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.

I appreciated your final word regarding "social reasons" and I think we're in strong agreement in that regard.

In the final analysis, it seems accurate to say that Microservices approach permits runtime operational [micro] payments towards organizational and analytical debt [1].

The hypothetical system(/straw man?:) you posit above is indicative of organizational, not architectural, failure/deficiency.

[1]: in the 'technical debt' sense.

Re: Microservices

#138

Post by regularfry »

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 embody the idea that there might not be a unified domain model across the organisation.

Re: Microservices

#139

Post by eternalban »

regularfry wrote: post #138
eternalban wrote: post #97

Earlier quoted context omitted.

> 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 embody the idea that there might not be a unified domain model across the organisation.

> there might not be a unified domain model

I agree with this. See my reply to mahyarm c.f. "analytical debt". Keyword here is "might not".

If there exists domain level solutions, incurring the (forever) micropayments (in context of operational complexities) of a rush to embrace microservices is a systemic fail of the technical leadership.

Re: Microservices

#140

Post by blazespin »

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…

Sounds like a great product.
Post reply on HN