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

61–70 of 152 posts

Re: Microservices

#61

Post by collyw »

fishtoaster wrote: post #26

There's some good points here and some I disagree with. One area, though, where I think he misses the point, is: > Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely, and not just the concept of building out code to live in a microservice. Rewriting an old Ruby on Rails, or Django, or NodeJS app into a language like Scala or Go…

> You can use postgres for the 99% of your app that's CRUDy and, I dunno, cassandra for the 1% where it makes sense. It's difficult (although not impossible) to do that cleanly within a monolith.

That sounds exactly like the last two apps I have worked on. Django / Flak based with Redis for caching. Suddenly they sound like trendy hybrid micro-service apps.

Re: Microservices

#62

Post by collyw »

gjolund wrote: post #29
lgunsch wrote: post #19

Earlier quoted context omitted.

I'm curious what makes you think that. At the end his bio says he has 12 years of experience, and from his blog seems to know a thing or two.

Because scaling a monolith is not a realistic approach. Every single monolith I have worked on has been refactored as domain specific microservices, and in every case it was a resounding success.

"I've never implemented monolith properly, so you should avoid them."

Re: Microservices

#63

Post by ai_ja_nai »

Why would someone push for those "5 thruths"? The point of microservices is to ease Ops life, so that deploying is less of a "big bang"-like event and more geared towards incremental and local evolutions.

Re: Microservices

#64

Post by pbreit »

mey wrote: post #4

From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined. Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated. I would love to understand how this article believes that the modules in…

Scaling is comparatively easy when compared to generating the amount of usage that actually requires scale. So it's pretty much a waste to think too much about it in the beginning (note that I am not granting permission to be sloppy).

Re: Microservices

#65

Post by pbreit »

jedberg wrote: post #12

This could be titled "If you do things wrong it won't be good". A lot of his examples are of people doing things poorly or incorrectly. I could make the same arguments about object oriented programming my saying it's bad because someone makes every function a public function. For example, microservices are absolutely more scalable if done correctly with bulkheading and proper fallbacks and backoffs, and proper monito…

That's a key point: it's easier to do things wrong/poorly on microservices.

Re: Microservices

#66

Post by abglassman »

Stabby! Several thumbs up to the point #1, that interface boundaries needn't be coincident with service boundaries. In my experience, the benefit of breaking out microservices is the decoupled deployment. A heuristic is, if you have fixes/features that are waiting to be pushed to production until unrelated code is passing/QA'd, you've got a good candidate for a separate service.

Re: Microservices

#67

Post by dragonne »

johns wrote: post #58
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…

We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the softwar…

We ship a microservices-based product on-premises. You can do it, but it's a heck of a lot of work. Plus you don't get any of the benefits microservices might bring in a CD scenario: you can't do CD over an airgap.

Re: Microservices

#68

Post by TickleSteve »

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

Re: Microservices

#69

Post by gimmeabreakguy »

mey wrote: post #4

From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined. Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated. I would love to understand how this article believes that the modules in…

Jesus christ. "Stick a load balancer in front of it and scale horizontally" works _precisely_ as well for a monolithic app as it does for a microservice. Which is to say, it might work, to some degree, to some total load, for some systems, and it might not for others, and will eventually break down at high enough load for pretty much anything that's not a pure function (e.g. you could scale a RESTful javascript linter horizontally presumably forever with more load balancers and more api servers, but your chat system is going to get more complex)

Re: Microservices

#70

Post by aikah »

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…

The problem with Micro-service is the notion of Micro. Services shouldn't be micro or macro but the right size. "Monolithic app" isn't a bad word, unfortunately some influential people tried hard to make it sound like it was.
Post reply on HN