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

Goodbye Microservices: From 100s of problem children to 1 superstar

segment.com

Post reply on HN
Print view View original

551–560 of 782 posts

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#551

Post by User23 »

scruffyherder wrote: post #531
maxxxxx wrote: post #512

Earlier quoted context omitted.

"From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism." I always tell people if you can't write and maintain a library then don't do microservices.

Yes the kids have just rediscovered the move from COM to DCOM. It's so silly that we are wasting so much time rebuilding existing things, poorly.

COM wasn't a picnic to work with back when it was the new thing. The toolchain sucked. I'll never write another line of MIDL in my life.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#552

Post by mdekkers »

It appears to me that this isn't so much a case of "microservices don't work" as it is the case of several poor architectural choices. It is always really easy to be part of the crowd in the peanut gallery and say "hah, you are doing it wrong", but when actually at the coalface the pressures and perspectives are different. Having said that, the microservices story isn't half as interesting as the Centrifuge story they link to in the article. Their approach (queues for everything) didn't work for them at their scale, so they invented something different (Centrifuge) that does. Poorly thought-out choices around microservices has little to do with the issue they solved.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#553

Post by sequoia »

tluyben2 wrote: post #417
StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

I have been doing some tech advice jobs on the side to see what's going on in the world and it's really scary what I found. Only yesterday I was talking with the cto of a niche social networking company that has a handful of users and probably won't get much more who was telling me the tech they use; Node, Go, Rust, Mongo, Kafka, some graph db I forgot, Redis, Python, React, Graphql, Cassandra, Blockchain (for their…

I had a similar experience last year as an advisor to a large "enterprise" type company. They are a slow-moving company with no competitive pressure & tons of compliance constraints, had several teams of Java engineers, they all know Java really well, they do not know JavaScript well. They had been attempting to migrate all their services to a modern, cool, bells & whistles JS SPA architecture.

Get ready for the surprise twist: It wasn't going well. I was hired as an expert JS consultant to advise them on which JS framework to use.

My advice? Get ready for surprise #2: "don't use javascript [or use it sparingly as needed]."

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#554

Post by User23 »

crimsonalucard wrote: post #514
wsy wrote: post #366

Earlier quoted context omitted.

It's a bit like asking to replace medical doctors with science and theory. We need science and theory, and skilled architects who can apply it to the problem at hand.

The practices of Doctors are based off of science and theory. Design patterns and microservices while technical are not based off of science. They are ideas without quantitiative basis or science.

Actually computing science is the most well understood science. Physicists can only give results with a few millionths* of accuracy, a computing scientist can prove a theorem about his subject matter with perfect accuracy.

Everyone else, including doctors, who call themselves scientists are just trying to float on the cachet physicists earned with their astonishingly good predictions. Properly speaking, they are phenomenologists . Please note that I'm not saying what they do isn't of great societal and intellectual value! The study and categorization of phenomena is certainly a noble enterprise. But none of them can make predictions good to 9 decimal places.

*might be billionths or quadrillionths by now in QED, but doesn't change my point.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#555

Post by eropple »

s73v3r_ wrote: post #446
eropple wrote: post #282

Earlier quoted context omitted.

The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools…

"But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago." Has it? I'm pretty sure if I were to ask what those best practices and tools are, I'd get a number of different answers.

Maybe.

But I bet they'd be the same ones those people used two years ago, or at least a really close variation.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#556

Post by parasubvert »

mikekchar wrote: post #486
johndubchak wrote: post #235

Earlier quoted context omitted.

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

You’re oversimplifying.

Architecturally speaking, there are some similarities between micro services and libraries because they’re both forms of modularization and usually have an API, but there are some stark differences beyond the “dispatch mechanism”.

The main difference is that a service’s deployment lifecycle is completely up to the service admin. Microservices are like websites - they can continuously evolve (within their API’s contract) without asking permission from consumers. This is their main superpower and why they’re a way of scaling a development organization without slowing it down too much.

In the case of a shared library, it’s completely up to the host admin as to when to upgrade. In the case of a static library, it’s up to the consuming software to determine when to upgrade. A service can upgrade when it feels like it.

Issues of API backwards compatibility, forwards compatibility, extensibility, self descriptiveness, versioning, etc. are old issues but usually have different answers when upgrades are truly happening all the time and not just in theory. It tends towards much fewer hard versions and more evolutionary backwards compatibility.

IOW, microservices aren’t a cure all, but they do encourage a set of behaviors. Many articles detracting from them seem to have not wanted those behaviors in their org in the first place.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#557

Post by staticassertion »

weberc2 wrote: post #550
staticassertion wrote: post #540

Earlier quoted context omitted.

2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice). Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely unhelpful, etc. Slow. Plenty of 'wat' like mistakes: https…

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonom…

> Yeah it is, choose 3. Python 2 is reaching EOL.

Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language.

3 is not the easy choice.

Anyways, maybe try nim? I've heard good things.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#558

Post by Floegipoky »

It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don't actually increase confidence in the correctness of the code they're negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway.

>> A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we wanted to deploy a change, we had to spend time fixing the broken test even if the changes had nothing to do with the initial change. In response to this problem, it was decided to break out the code for each destination into their own repos

They also introduced tech debt and did not responsibly address it. The result was entirely predictable, and they ended up paying back this debt anyway when they switched back to a monorepo.

>> When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase... Eventually, all of them were using different versions of these shared libraries.

To summarize, it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#559

Post by maxxxxx »

User23 wrote: post #551
scruffyherder wrote: post #531

Earlier quoted context omitted.

Yes the kids have just rediscovered the move from COM to DCOM. It's so silly that we are wasting so much time rebuilding existing things, poorly.

COM wasn't a picnic to work with back when it was the new thing. The toolchain sucked. I'll never write another line of MIDL in my life.

Agreed. Although with tools like Visual Basic it was quite nice to use. Now, DCOM was another story. Pretty much everybody I knew who used it started to become suicidal after a while...

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#560

Post by scrollaway »

weberc2 wrote: post #550
staticassertion wrote: post #540

Earlier quoted context omitted.

2 or 3? Or all of the problems that come with choosing between the two (no, it is still not an easy choice). Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely unhelpful, etc. Slow. Plenty of 'wat' like mistakes: https…

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonom…

Re your last paragraph, you're describing Lua.

I don't know the state of its coroutines though as I've never used them.

Post reply on HN