Live data from Hacker News

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

segment.com

311–320 of 782 posts

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

#311
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…

The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than…

One person's trash is another person's treasure.

Part of the reason SQL has stood the test of time is the very fact that it allows such a high level of abstraction. The big problem that it solved, compared to much of what existed at the time, was that it allowed you to decouple the physical format of the data from the applications that used it. That made it relatively easy to do two things that were previously very hard: Ask a database to answer questions it wasn't originally designed to answer, and modify a database's physical structure without having to change the code of every application that uses it.

A lot of "easier" technologies - including, arguably, ORM on top of relational databases - make things easier by sacrificing or compromising those very features that allow for such flexibility. Which speaks to the grandparent's point about technologies that make it easy to get started in the short term, at the cost of having major disadvantages in the long term.

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

#312
post #243

Earlier quoted context omitted.

What examples are you thinking of with “Everyone slowly goes back to the old technology?”

The first that comes to mind is mainframe. Just the only name for cloud computing.

Well, with mainframes, there was a very good reason that the industry went to PCs. The networking infrastructure just wasn't there. Now, fiber connections are becoming ubiquitous and intranets are super fast, mainframe computing makes sense again. (not that it ever went away, but the real world use cases for mainframe computing has really caught up to the original vision.)

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

#314
post #157

Earlier quoted context omitted.

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever). The irony being that anything approaching SOA (or micro…

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…

No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases.

An architect is just a another man with an opinion.

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

#315

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…

Sharing schemas and contracts in a distributed architecture is a hard problem. The interesting thing is these are central to communication, so we should definitely talk as a team about them - if anything, that's probably the one thing if you had to choose what to talk about. Then the INTPs can scurry back to their holes and continue creating stuff while the ENFPs form a committee for the next pub walk. Full disclosur…

Sharing schemas and contract's isnt a hard problem. Toss them in a shared repo and push it to artifactory. Anyone who updates it increments the repo. Done.

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

#316
post #312

Earlier quoted context omitted.

The first that comes to mind is mainframe. Just the only name for cloud computing.

Well, with mainframes, there was a very good reason that the industry went to PCs. The networking infrastructure just wasn't there. Now, fiber connections are becoming ubiquitous and intranets are super fast, mainframe computing makes sense again. (not that it ever went away, but the real world use cases for mainframe computing has really caught up to the original vision.)

The only difference is that modern terminals are prettier.

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

#317

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…

And, in the end, everyone starts writing Java again...

I never stop doing it.

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

#318
post #176

I wonder what language they're using? > if a bug is introduced in one destination that causes the service to crash, the service will crash for all destinations. This sounds dangerous. If I was a destination provider, and returned some garbage, could that take system down? Also, reading up on centrifuge, instead of breaking up by source, destination; would it be more spatially conservant to create queues by response t…

The examples are written in JavaScript but it also looks like they use Go. Not sure which language this service is using specifically.

This particular destination service is written in JavaScript.

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

#319
post #7

Earlier quoted context omitted.

unless they have 100 developers for 100 services. That cure is worse than the disease. Every service works differently and 80% of them are just wrong, and there’s nothing you can do because Tim owns that bit.

Not to mention you have 2^100 states of on/off (~1.2676506e+30)

I work on that project. Every time some idiot starts talking about 'code coverage' my face turns red. Our code coverage is 1e-10%. Don't talk to me about this 70% bullshit.

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

#320

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…

Also, write a treatise about how they discovered queueing theory... seems to be part of the pattern.
Post reply on HN