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

371–380 of 782 posts

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

#371

Post by wsy »

digi_owl wrote: post #209
paxys wrote: post #155

Earlier quoted context omitted.

Look at the package dependency tree of an average linux program. They are absolutely examples of "microservices" talking to each other.

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.

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

#372

Post by tabtab »

JustSomeNobody wrote: post #353
crimsonalucard wrote: post #276

Earlier quoted context omitted.

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…

> Different permutations of identical queries causes slow downs or speed ups for no apparent reason in SQL. EXPLAIN does a very good job of explaining why one query is faster than another. > SQL is a leaky abstraction that has created a whole generation of SQL admins or people who memorize a bunch of SQL hacks rather than understand algorithms. This just smacks of sound bite material.

To misquote Winston Churchill, SQL is the worst data approach except for all others. As far as query languages, I'd like to see more language competition. I imagine it would take a decade or two to be competitive with SQL, which has a big head start. (I'm partial to SMEQL myself.)

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

#373

Post by Symbiote »

pjmlp wrote: post #308
0x445442 wrote: post #210

Earlier quoted context omitted.

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.

Which is actually an English issue how to describe it. In Portuguese it is never called Computer Science as such, rather Informatics, Computation or Informatics Engineering if I do a literal translation. And those that have Engineering in their name, are only allowed to be called that way if recognised by the Engineers country organization as such.

It's not an English language problem, terms like informatics[0], computing, computation or engineering are valid and used by some universities.

My degree is simply "MEng Computing". It's recognized[1] by the engineering association, although that's so irrelevant in most IT that I had to look up the organization: the "BCS (BCS - Chartered Institute for IT) and the IET (Institute of Engineering and Technology)."

[0] My job title includes the word "informatician".

[1] https://www.imperial.ac.uk/computing/prospective-students/ac...

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

#374

Post by eropple »

clon wrote: post #361
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…

I had managed to instill into my brain that Webpack is the JS moving target du jour. I am blown away that it has already been "surpassed" before our team managed to even have a serious review of it. Parcel it is then.

It isn't, though. I expect Parcel will eventually be superceded again by Webpack, and continue to use it for new projects because it's more entrenched.

And, moreover, it basically doesn't matter. Pick what you like, change it later if you care. (You probably won't.)

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

#375

Post by curun1r »

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…

With hype always comes a throng of people who aren't capable of doing the necessary analytical thinking to solve their problem and who think they can substitute a magical pattern for designing their application instead of truly understanding their problem domain and building a real solution to that problem.

Does that make it the fault of the technology/pattern? I don't think so. I think it just means that there's no magic bullets in tech and people who don't know what they're doing will always cause problems no matter what models they follow.

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

#376

Post by jiveturkey »

acroback wrote: post #123

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…

> This means, everytime you touch something under a repo, it affects everyone.

This is horrible at scale.

> This is a classic case of not understanding micro services and trying to fit a problem around a tool.

That much I agree with. TFA even acknowledges that, in the conclusion. Not in so many words, but they basically admit they did it wrong.

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

#377

Post by ninkendo »

ascendantlogic wrote: post #249
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…

Which is why I feel like after 20 years in the industry a good portion of people start consultancies realizing there's good money to be made on this hype cycle churn.

It's like a heat engine of hype that you can extract useful energy from.

    $_max = 1 - (H_c / H_h)
That is, the amount of money you can extract via consulting is proportional to the ratio of "hot" to "cold", representing the minimum and maximum hype for a given technology during the cycle.

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

#378

Post by wsy »

ljw1001 wrote: post #252
VBprogrammer wrote: post #143

Earlier quoted context omitted.

That architecture is commonly known as a distributed monolith. If you put two services on the same DB you can guarantee that someone will be joining onto a table they shouldn't have before the week is out.

This is another way of saying that micro-services are for easy problems, where you can avoid having many processes share the same complex database.

It's exactly the other way around:

If you can afford all your components sharing the same database without creating a big dependency hell, then your problem is _too small_ for microservices.

If your problem is so large that you have to split it up to manage its complexity, start considering microservices (it might still not be the right option for you).

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

#379

Post by alexanderscott »

This misses the mark completely. A separate repo and service simply for different serialization and routing? Each performing the same basic function. That’s not a legitimate use-case for microservice separation and was doomed from the start.

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

#380

Post by tabtab »

byebyetech wrote: post #211
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 :)

Bob Martin said in one of his lectures that Software Engineering is the only field where people can't even agree on one thing.

Once we got into a big discussion at c2.com about "proving nested blocks were objectively better than go-to's". Being most agreed nested blocks are usually "better", it seemed like it would be an easy task. Not! Too much depends on human psychology/physiology, which both varies between people, and is poorly understood. We couldn't even agree on a definition of nested blocks, being hybrid structures were presented as case studies.

I personally believe nested blocks produce a visual structure (indenting) that helps one understand the code by its "shape". Go-to's have no known visual equivalent.

Computers don't "care" how you organize software, they just blindly follow commands. Thus, you are writing it for people more than machines, and people differ too much in how they perceive and process code. For the most part, software is NOT about machines.

Post reply on HN