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

571–580 of 782 posts

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

#571

Post by crimsonalucard »

johndubchak wrote: post #362
crimsonalucard wrote: post #314

Earlier quoted context omitted.

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.

We have these things. A better architect implies that one is trained in analyzing and producing these architectures using the science she/he was trained with: https://www.sei.cmu.edu/education-outreach/credentials/crede... The certificate means nothing, the training and instruction is priceless. Add to that things like TOGAF and a deep understanding of the current state of existing architectures and you'll understand…

The closest mathematical formal system I've seen that dictates architecture is category theory. But even this system doesn't say anything about being "better" or more efficient than another design pattern.

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

#572

Post by pweissbrod »

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…

Ok so if I want to build a fledgling project all I need to do is leverage a language nobody uses yet. Lolcats ftw.

Seriously though constraining dev's to use a monolithic repository in the name of discouraging cowboys is like tying people's legs together to ensure they walk in an aligned direction. Sure it works but seriously unnecessary pain. Your company should invest in integration tests

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

#573

Post by timr »

chrisco255 wrote: post #567
timr wrote: post #409

Earlier quoted context omitted.

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…

I wouldn't. React makes it hard to FUBAR a front end. JQuery makes it stupidly easy to write a spaghetti code unmaintainable mess.

React makes it easier for bad developers to do complicated things. They still end up writing spaghetti code.

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

#576

Post by stickfigure »

davewritescode wrote: post #527
thermodynthrway wrote: post #460

Earlier quoted context omitted.

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…

Data consistency is one of those things that sounds like it matters but often doesn't. There's not much in Netflix's platform that screams data consistency is an ultra high priority. Any application that deploys active/active multi-region is by definition going to encounter scenarios where data loss is possible. There's just no way around CAP. I'd venture a guess that most applications have all sorts of race conditio…

A little birdie who worked at Grab once told me that they pretty much don't use transactions anywhere. So... maybe there are problem domains where you can get away without transactions, but I'm quite sure that a marketplace that arranges transportation for fee is not one of them. The next time you're standing in a monsoon waiting for the "coming" car that never comes, remember this post :-)

Aside from that, I've found that even in non-mission-critical scenarios ("it's just porn!") it's incredibly convenient to have a limited number of states the system can be in. It makes debugging easier and reduces the number of edge cases ("why is this null??") you have to handle.

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

#577

Post by sagichmal »

thermodynthrway wrote: post #460
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…

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…

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

No, you just need loosely-coupled services, where inconsistency in this circumstance doesn't manifest as a problematic end-state.

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

#578

Post by eitally »

crimsonalucard wrote: post #569
agentultra wrote: post #542

Earlier quoted context omitted.

Model checking is based off of mathematics and can be verified or, with some elbow grease, proven . I'll take a TLA+ specification over a diagram any day.

What do you mean by model checking? Usually anything with the keyword "Design" like design patterns for microservices have no science or mathematics to back it up.

You may be technically correct, but I'd argue it's generally more useful what we do have: practical experience. When one says "we need better architects", to me that implies that our current architects are creating design patterns and reference implementations that are both 1) not practical, and 2) don't adhere to known-good best practices.

Systems design in real life is an "artistic science": there are always known limitations (and some expected unknown ones) that rule out the theoretic optimal design for good reasons. The problem is that limitations and compromises are often not disclosed, and that many programmers and architects are too inexperienced to really grok the implicit meaning behind specific design decisions.

So we struggle along, with bloggers, researchers and FOSS contributors halfheartedly collaborating to make point improvements as solutions are discovered. Stodgy enterprises suffer, big tech companies make decisions with global impact, startups are left wondering WTF to do, and the rest of us largely don't care. Why? Because nit picking doesn't solve business problems [almost ever. I'd argue this point in cases of things like SCADA systems and other mission critical control systems.].

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

#579

Post by eitally »

jdoliner wrote: post #547
jiveturkey wrote: post #376

Earlier quoted context omitted.

> 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.

> This is horrible at scale. This can work fine at scale, Google does it with however many tens of thousands of engineers they have these days. Having everything in a monorepo doesn't solve the communication problem, it doesn't prevent solving it either.

Sort of. Google is also well known for having a dozen chat apps. What most people don't know is that there are also likely a dozen different libraries/utilities/interfaces performing near identical services just because an engineer or product team weren't 100% satisfied with what already existed. So yes, it's a monorep, but holy heck there's a lot of duplicative cruft.

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

#580

Post by eitally »

stickfigure wrote: post #478
jiveturkey wrote: post #376

Earlier quoted context omitted.

> 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.

>> This means, everytime you touch something under a repo, it affects everyone. >This is horrible at scale. I just want to reiterate this. In the early 2000s I worked in the online platform group at EA. The list of things done poorly there was long, but picture: * 40+ engineers * Monorepo with hundreds of thousands of classes; all code deployed to all servers. * Hundreds of different services running across thousands…

Funny that it was this bad at an actual tech company. What you described is pretty common in normal big enterprise, though.
Post reply on HN