Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

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

#451

Post by Deadron » Tue, Jul 10, 2018, 10:20 PM UTC

52-6F-62 wrote: post #266

irrational wrote: post #250

Earlier quoted context omitted.

Not OP, but recently a group at my company abandoned MongoDB and went back to a relational database after going through the exact scenario outlined by the OP (actually, the OP's comment so closely aligned with what happened that I actually wonder if he/she is actually a developer with that team at my company ;-)

Interesting. I'm currently working MongoDB into a couple of projects I have going at work (they're not really outward facing except for potentially one generated view). For these projects it seemed to make a ton of sense given the rest of the stack, the nature of the projects, the deadlines I'm facing, and I've really loved working with it so far. Why did you end up moving off of it?

The simple fact is mongoDB fails to have sufficient durability guarantees for business data when compared to a traditional RDBMS. That is one of the reasons why its so fast in comparison. A power loss event during data writes can and will lead to data loss.

https://www.mongodb.com/blog/post/what-about-durability

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

#452

Post by sheepmullet » Tue, Jul 10, 2018, 10:22 PM UTC

tabtab wrote: post #380

byebyetech wrote: post #211

Earlier quoted context omitted.

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…

> and people differ too much in how they perceive and process code.

Yes, for example I love dense code. A 1 line regex is a lot simpler to me than the 50-60 lines of code equivalent.

Yet some programmers find the 1 line regex significantly more difficult even if they know regex.

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

#453

Post by [deleted] » Tue, Jul 10, 2018, 10:24 PM UTC

timr wrote: post #409

chrisco255 wrote: post #274

Earlier quoted context omitted.

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

[deleted]

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

#454

Post by avarun » Tue, Jul 10, 2018, 10:25 PM UTC

lgunsch wrote: post #386

kllrnohj wrote: post #205

Earlier quoted context omitted.

JavaScript prior to ES6 was "old" and obsolete and hated. Building JS objects pre-classes is pretty terrible (to say nothing of the .bind(this) that is spammed everywhere without the => operator) JS has improved massively over the last few years, it's very nearly an entirely different language than what it used to be. There's a reason everyone was desperate to avoid writing JS not all that long ago be it the form of…

Interesting. I haven't touched, or even read, any JavaScript since well before ES6 arrived. I suppose I don't really know the language if it's changed so much (I've never even heard of JavaScript classes). I jumped on the JavaScript hater train and left the station.

>I jumped on the JavaScript hater train and left the station.

As does most of Hacker News with every technology they hate on.

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

#455

Post by eximius » Tue, Jul 10, 2018, 10:27 PM UTC

> The shared libraries made building new destinations quick. The familiarity brought by a uniform set of shared functionality made maintenance less of a headache.

> However, a new problem began to arise. Testing and deploying changes to these shared libraries impacted all of our destinations. It began to require considerable time and effort to maintain. Making changes to improve our libraries, knowing we’d have to test and deploy dozens of services, was a risky proposition. When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase.

When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase.

I think I see the problem and it wasn't with microservices.

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

#456

Post by jchanimal » Tue, Jul 10, 2018, 10:27 PM UTC

mgkimsal wrote: post #449

keithnz wrote: post #336

Earlier quoted context omitted.

sounds like an awesome idea! Anyone who wants to do a startup around this I have an awesome idea about how to implement this using blockchain and a serverless tech stack :D

I'm still waiting for serverless blockchain to be its own buzzword.

Serverless smart contract dapp-as-a-service.

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

#457

Post by stickfigure » Tue, Jul 10, 2018, 10:28 PM UTC

madamelic wrote: post #163

stickfigure wrote: post #40

Earlier quoted context omitted.

It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. I've never quite understood why people think that taking software modules and separating them by a slow, unreliable network connection with tedious hand-wired REST processing should somehow make an architecture better. I think…

>It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. If two microservices have to share databases, they shouldn't be microservices. One microservice should have write access to one database and preferably, all read requests run through that microservice for exactly the reason yo…

My problem with microservices is the word 'micro'. It should just be services.

Problem domains (along with organizational structures) inherently create natural architectural boundaries... certain bits of data, computation, transactional logic, and programming skill just naturally "clump" together. Microservices ignore this natural order. The main driving architectural principle seems to be "I'm having trouble with my event-driven dynamically-typed metaprogrammed ball-of-mud, so we need more services!".

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

#458

Post by pnloyd » Tue, Jul 10, 2018, 10:29 PM UTC

keithnz wrote: post #336

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…

sounds like an awesome idea! Anyone who wants to do a startup around this I have an awesome idea about how to implement this using blockchain and a serverless tech stack :D

Serverless is my most hated buzz word, even if I like what it actually means. I mean come on, there are always servers.

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

#459

Post by rstefanic » Tue, Jul 10, 2018, 10:34 PM UTC

rubatuga wrote: post #299

rstefanic wrote: post #242

Earlier quoted context omitted.

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.

Sure, I don't think anyone would disagree with you on that.

But still, how is the initial comment an example of the Hegelian Dialectic?

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

#460

Post by thermodynthrway » Tue, Jul 10, 2018, 10:39 PM UTC

stickfigure wrote: post #40

davidkellis wrote: post #5

Earlier quoted context omitted.

> You push data consistency concerns out of the database and between service boundaries. Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data…

It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. I've never quite understood why people think that taking software modules and separating them by a slow, unreliable network connection with tedious hand-wired REST processing should somehow make an architecture better. I think…

I've heard of even Unicorns throwing consistency out the window. Apparently Netflix has a bunch of "cleanup jobs" that comb the database for various inconsistencies that inevitably show up.

You can't have consistent microservices without distributed transactions. If a service gets called, and inside that call, it calls 3 others, you need to have a roll back mechanism that handles any of them failing in any order.

If you write to the first service and the second two fail, you need to write a second "undo" call to keep consistent.

Worse, this "undo state" needs to be kept transactionally consistent in case it's your service that dies after the first call.

In reality, nobody does this, so they're always one service crash away from the whole system corrupting the hell out of itself. Since the state is distributed, good luck making everything right again.

Microservices are insane. Nobody that knows database concepts well should go near them