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

81–90 of 152 posts

Re: Microservices

#81

Post by xorcist »

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…

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?

Re: Microservices

#82

Post by euske »

I heard about microservices about a year ago, and now it said the hype has ended before I even noticed? Admittedly I'm not in the loop, and it's hard to track all the trends from outside.

Re: Microservices

#83

Post by josh_carterPDX »

StabbyCutyou wrote: post #46
josh_carterPDX wrote: post #43

My thought is that this comparison between a monolithic code base vs a microservices code base is a bit subjective. If you're starting out chances are your code base hasn't even gotten to the level of being monolithic. So those thinking about how they're going to architect their platform may begin to think that a microservice setup could help for future changes to their code. It really depends on each team, their bac…

You have a good point in that in the early stages, any app is likely not to be a "monolith", but it's less about size/LOC and more about the design ethic of the architecture itself. If you build your codebase internally with service level abstractions in mind, you can gain a lot of benefit without the cost of the network or the additional errors it can introduce. Thanks for reading!

I guess, in my head it's also eliminating a lot of code bloat using microservices. Just my opinion though.

Re: Microservices

#85

Post by naasking »

oelmekki wrote: post #79
naasking wrote: post #76

Earlier quoted context omitted.

> Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. There's already a term for that: modularity.

A word which totally not carries lessons learnt from microservices vs monoliths. But using that name is fine by me, I'm not trying to define other people world, just sharing mine.

I think it does carry those lessons, but most languages are incredibly bad at enforcing modularity. Monoliths make it far too easy to cheat, and dynamically typed languages are typically worse here.

Microservices then just forces on you the modularity your language should have already given you.

Re: Microservices

#86

Post by ceslami »

txutxu wrote: post #39
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…

I see microservices as responsibility deduplication in a organization-traversal-wide. De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones). Thinking organization-traversal-wide is what is hard for some persons. Currently working at consulting in a big corp... you get to this problem: Resource: name FooBar, type int (organization view…

> Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective?

An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.

Re: Microservices

#87

Post by jsmith0295 »

xorcist wrote: post #81
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…

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.

Re: Microservices

#88

Post by [deleted] »

robotresearcher wrote: post #30
sbov wrote: post #25

Earlier quoted context omitted.

Yeah, scaling app code is generally a solved problem: shared nothing with some load balancers. It doesn't work for every problem, but the above has been standard in my circles for at least a decade by now. Databases are trickier though.

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

[deleted]

Re: Microservices

#89

Post by dwmtm »

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 is a great list.

When micro services work, it's because they made it easy to verify each of these [obvious] bullet points. For some jobs, file this under premature contemplation.

When other methods work... My top two are "clarity of focus" and "[relative] lots of unnecessary labour". "Lifecycle" takes a coalition third.

Re: Microservices

#90

Post by StavrosK »

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.

Post reply on HN