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

91–100 of 152 posts

Re: Microservices

#91

Post by vhost- »

It doesn't have to be messy. I've worked in monoliths that are a complete disaster. I've worked in micro-architectures that are a complete disaster. It's the same kinds of people and management practices making these disasters.

I will say the only clean systems I've worked in have been microservice oriented. All monolithic systems I've worked on never scaled properly and always had bugs with 1000 function deep stacktraces.

I've talked to people who have worked in excellent monoliths (rails and django). I know they exist.

Moral is: do it right and have good development practices.

Re: Microservices

#92

Post by deathanatos »

> Fallacy #5: Better for Scalability

> However, it’s incorrect to say that you can only do this with something like a microservice. Monolithic applications work with this approach as well. You can create logical clusters of your monolith which only handle a certain subset of your traffic. For example, inbound API requests, your dashboard front end, and your background jobs servers might all share the same codebase, but you don’t need to handle all 3 subsets of work on every box.

This makes little to no sense to me, and feel like we're bending the definition of "monolith" to mean "microservice" so that we can tick the bullet point. How, exactly, do I achieve this, when my code is mashed together and all running together?

I have a monolithic app today: an internal website, which is so small that it could be served (ignoring that this would make it a SPoF) from a single machine. But it's so closely bound to the rest of the system, it is stuck alongside the main API. So, it gets deployed everywhere.

If it were discrete enough that I could run and scale that internal service separately, I wouldn't be calling it a monolith. At that point, they're separate executables, and scalable independently — that's practically the definition of microservice. And I can't do this if (where they need to) they don't talk over the network (one of the earlier bullet points).

Re: Microservices

#93

Post by wstrange »

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…

I think this is where Kubernetes has potential.

You can bundle up those complex dependencies into deployment manifests, or use helm.

It's like a SAAS in a box

Re: Microservices

#94

Post by happychappy »

deathanatos wrote: post #92

> Fallacy #5: Better for Scalability > However, it’s incorrect to say that you can only do this with something like a microservice. Monolithic applications work with this approach as well. You can create logical clusters of your monolith which only handle a certain subset of your traffic. For example, inbound API requests, your dashboard front end, and your background jobs servers might all share the same codebase, b…

If you could separate the inbound traffic to either the website or the API, then you could do this. You'd need something in front of the code you're deploying though

My team has a 500k monolith written in java 1.6. I don't really want to invest in fixing it, I'm migrating stuff to the new system. So a way to keep the old one going risk-free is to create three load balancer pools, and have apache send some traffic to the three based on URL pattern

* /users goes to pool one * /dashboards goes to pool two everything else goes to pool three

That guarantees that /users and /dashboards can be kept to certain level of performance - by adding more machines, not by diving into the code and trying to fix stuff.

The benefit is that its the same deployable in all cases, so its very easy to push.

Re: Microservices

#95

Post by mahyarm »

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.

Re: Microservices

#96

Post by mr337 »

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.

ha this is a great flowchart!

Re: Microservices

#97

Post by eternalban »

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 need "engineers".

> Microservices are good for large companies.

And this has nothing to do with number of developers. It has to do with inherent complexity of a unified domain model for large organizations. As an analogy, consider microservices as scripting to layered architectures compiled language.

Re: Microservices

#98

Post by bunderbunder »

blowski wrote: post #72
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…

Interestingly, the Sam Newman book about Microservices specifically says it's easier to succeed by starting with a monolith that you then break up. That advice does seem to be ignored by people who want a microservice architecture because it looks good on their CV, or because they think it will magically solve a bunch of hard problems they don't know how to solve.

I believe it.

The best place to place a module boundary - and the best format for communication across that boundary - is rarely completely transparent from the outset. With a monolith it's relatively easy (if not actually easy) to fiddle with those details until you get them right. With a service it can be very difficult to iterate on this stuff, so unless you're very confident you'll get it right on the first try, it's best to get a bit of experience in the problem domain first.

Re: Microservices

#99

Post by matwood »

blowski wrote: post #72
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…

Interestingly, the Sam Newman book about Microservices specifically says it's easier to succeed by starting with a monolith that you then break up. That advice does seem to be ignored by people who want a microservice architecture because it looks good on their CV, or because they think it will magically solve a bunch of hard problems they don't know how to solve.

I think microservices can work well, but also agree that it's easier to start with a monolith. It's hard to go out and create perfect microservices. In my experience they emerge from the problem much like how an amoeba gets big and breaks off at natural points.

Re: Microservices

#100

Post by michaelcampbell »

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.
Post reply on HN