Live data from Hacker News

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

segment.com

291–300 of 782 posts

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

#291

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.

Reminds me of the opening lines of the SICP lectures[0]:

"I'd like to welcome you to this course on Computer Science. Actually that's a terrible way to start. Computer science is a terrible name for this business. First of all, it's not a science. It might be engineering or it might be art. We'll actually see that computer so-called science actually has a lot in common with magic. We will see that in this course. So it's not a science. It's also not really very much about computers. And it's not about computers in the same sense that physics is not really about particle accelerators. And biology is not really about microscopes and petri dishes. And it's not about computers in the same sense that geometry is not really about using a surveying instruments."

[0]: https://www.youtube.com/watch?v=2Op3QLzMgSY

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

#292

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…

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

Linux is the kernel.

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

#293
post #263

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

> all JS services go under js/ Aww, no clever name or the JS services?

badlanguage/ is too long

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

#294
post #28
post #17

Earlier quoted context omitted.

"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…

Is there any evidence of this being true? Do they actually force a discipline? Do people actually find swapping languages easier with RPC/messaging than other ffi tooling? And do they really attract talent?! You make some amazing claims that I have seen no evidence of, and would love to see it.

Pure anecdote so I know it is meaningless but I have rewritten/refactored old services with new code, or even new languages twice with little problem because the interface was well defined. We had hundreds of devs working in other areas and we were all on different release cycles because changes were easy and decoupled. We let any team submit bug reports when we either weren't complying with our interface or we had a bug somewhere.

The only teams I had to spend time on were the ones which were on a common DB before we moved off of it.

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

#296
post #60

> While our systems would automatically scale in response to increased load, the sudden increase in queue depth would outpace our ability to scale up, resulting in delays for the newest events. This strikes me as the core of their problem, and every step taken was a way to bandaid this limitation. Would the cost of moving to faster-scaling infrastructure been so high as rearchitecting the entire system? > When we wan…

The job of these services is to transform their internal event format to 140 different output formats. You can imagine that there is a lot of duplication in the functionality that these services need to do. Are you suggesting that they avoid any shared libraries and just rewrite the same code over and over hundreds of times and update them independently?

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

#297

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.

After Rails burned through the hype cycle, its entire niche had disappeared. The skinny-jeans hipsters had moved on to single page apps and Node.JS and the "let's try and use Rails to write backend services" crowd had dispersed to a variety of better technologies.

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

#298

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…

> 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?!"

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

#299

Earlier quoted context omitted.

yup. basically Hegel's dialectic: https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic Thesis --> Antithesis --> Synthesis

How is this an example of the Hegelian Dialectic?

Because the world isn’t the same after the two competing technologies have fought it out.

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

#300
post #244

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…

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…

Still doing jQuery with server side rendering, not bothering with React. Yep dinosaur here.
Post reply on HN