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

401–410 of 782 posts

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

#401

Post by thermodynthrway »

nickthemagicman wrote: post #127
hinkley wrote: post #42

Earlier quoted context omitted.

People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution". You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation. You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.

It seems like a Big Ball of mud is much more difficult to deal with than a bunch of small balls of mud just in general?

A thousand small balls of mud that communicate with each other randomly is nearly impossible to grok because the IDE can't save you

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

#402

Post by wsy »

scarface74 wrote: post #142
ivan_gammel wrote: post #137

Earlier quoted context omitted.

Mocking modules for unit testing - yes. Testing the specific build artifact with a module replaced by a mock - no, it is not.

A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment. IOrderService -> OrderService in production. IOrderService ->FakeOrderService when testing.

You will end up with something like OSGi. That can be the right choice, but is also a quite 'heavyweight' architecture.

For a certain class of applications and organizational constraints, I also would prefer it. But it requires a much tighter alignment of implementation than microservices (e.g., you can't just release a new version of a component, you always have to release the whole application).

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

#403

Post by mavelikara »

copperx wrote: post #187
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 can't find the right place for Ruby on Rails here. It doesn't fit.

Rails' extensive use of monkey patching to implement features is currently out of favor, from what I understand.

Also, by merging Merb in Rails 3, Rails got a fresh lease of life. This is similar to how Struts lived on by rebranding WebWork as itself.

Finally, Ruby shows up prominently as a language developers dislike: https://stackoverflow.blog/2017/10/31/disliked-programming-l...

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

#404

Post by marcosdumay »

stcredzero wrote: post #298
bumholio wrote: post #280

Earlier quoted context omitted.

> Now that everyone forgot why the new technology was bad, we're free to begin the cycle again. We can very easily break the cycle by training a deep learning TensorFlow brain in the cloud, that will be fed the daily mouse gestures and key presses of all developers in the world. It's an awesome new technology that can solve any problem. Pretty soon the global brain will start to see patterns emerging, for example whe…

"But if he was shocked, he wouldn't bother to keep typing!" "Maybe he was taking dictation?!"

Nah... This one was clearly paralized while pressing a key. His browser must auto-post HN comments after a short while.

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

#405

Post by web007 »

jarfil wrote: post #236

The whole article reads like BS to me. So the initial problem was a single queue? Well, then split the queue, no need to go all crazy splitting all the code. Switching to 100+ microservices? There is no need to switch to 100+ repos too, runtime services don't need to have one repo per service, just use a modular approach, or even feature flags. 100+ microservices, some of them with much lower load than others? Then c…

> Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.

This answer drove me crazy in the article. "We had trouble keeping the libraries up to date and fixing breakages, so our solution was... to update them all and fix the breakages." And per your second point, tests can go both ways - if libX is used by serviceY, write a libX integration test for serviceY instead of / in addition to a serviceY integration test for libX.

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

#406

Post by digi_owl »

wsy wrote: post #371
digi_owl wrote: post #209

Earlier quoted context omitted.

And they can be a right mess to wrangle because upstream gets into some artistic frenzy, and shouts down anyone that worries about the ensuing breakages as luddites and haters.

And still nobody would argue to pack everything together into one executable because of these issues. As everything in software engineering, it is about finding the right trade-off.

Oh, but why do that when we have containers...

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

#407

Post by jacquesm »

lagadu wrote: post #390
jacquesm wrote: post #220

Earlier quoted context omitted.

I've seen worse. And I wished that I was kidding.

Storytime?

Every microservice on its own little cluster of VMs for HA and performance...

A couple of hundred VMs is nothing in a scenario like that. Good luck trying to debug anything.

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

#408

Post by zjaffee »

0x445442 wrote: post #210
resource0x wrote: post #198

Earlier quoted context omitted.

> Old technology is deemed by people too troublesome or restrictive. "deemed" is the keyword here. Old tech is "deemed" bad, new one is "deemed" good. Without any numbers attached, just by way of hand-waving and propaganda. And it's all "deemed" Computer Science :)

Computer Science... Now there's an oxymoron. At most institutions the subject matter is not really about computers nor is it science, at least not in the physics or chemistry sense.

Science can be both experimental and formal (see Math). This said, there are certainly aspects of CS that require collecting data, designing experiments, ect.

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

#409

Post by timr »

chrisco255 wrote: post #274
craigc wrote: post #244

Earlier quoted context omitted.

Yup. Everyone wants to use the latest and greatest, but there is a reason that certain things like SQL have stood the test of time. I think the same could be said of the design world. There was a time not too long ago when designs actually felt polished and had real shapes, shadows, gradients. When you clicked on a button you actually knew you were clicking on a button. Then iOS 7 came along and everything became whi…

Ha, JQuery. I just had to look at a legacy JQuery code base...and I shudder the thought of ever going back to that paradigm. Sometimes new patterns/frameworks/architectures do really change the game for good.

I still use jQuery regularly. It works well and doesn't get in the way. I'd rather work on a jQuery codebase written by a good engineer than a React codebase written by an average engineer, and there's no amount you could pay me to work on a Javascript codebase written by a bad engineer.

The problem you've identified is that most code, in general, is terrible. The code written by people who chase trends tends to be worse than average.

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

#410

Post by buckminster »

dualogy wrote: post #17
thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…

I was doing this with COM twenty years ago. It had the same advantages of modularity and language independence but without the unnecessary headaches of a distributed system.

I take your point, but it saddens me that there aren't better ways of achieving this modularity nowadays.

Post reply on HN