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

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

#481

Post by amclennon » Tue, Jul 10, 2018, 11:14 PM UTC

acjohnson55 wrote: post #465

craigc wrote: 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…

You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago. So really it would be more like React vs vanilla JS. There's definitely a place for vanilla, when you just need minor dynamism on an otherwise basic UI.

> You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago

You say that, but from time to time I still discover slight variations in browser behavior or bugs that were opened 8 years ago that would've been avoided if I had just used jQuery. Most modern frameworks will abstract away these differences, but sometimes you'll need to access the DOM directly.

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

#482

Post by skyisblue » Tue, Jul 10, 2018, 11:15 PM UTC

Microservices benefits large teams. There’s just too much operational overhead for a small team to manage microservices. Large teams with monolith applications benefit from microservices as the communication issue of large teams is reduced by splitting the team into cross functional teams.

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

#483

Post by dnomad » Tue, Jul 10, 2018, 11:17 PM UTC

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…

What this actually looks like is a case of very imperfect knowledge transfer within the technology industry. What's interesting about the entire craze of microservices and containers and the cloud is that they are not a new technology. This entire architecture -- the so-called lambda architecture -- has been the standard approach to developing high-performance trading systems on Wall St. since the early 90s. The architecture is literally 30 years old and certain technologies (event sourcing, event driven architecture) are even older.

The problem is that the all the best knowledge has clearly not made it out. For example, this design introduces a "Centrifuge" process that redirects requests to destination specific queues... congratulations you've just reinvented a message bus, a technology that goes back to the 80s. There is absolutely nothing new about virtual queues as described here but unfortunately the authors are likely not at all aware of the capabilities of real enterprise messaging systems (even free, open-source ones like Apache Artemis) and certainly not aware of the architecture and technologies and algorithms that underlie them and the (admittedly much more expensive) best-of-breed commercial systems.

(I won't even go into the craziness of 50+ repos. That's just pure cargo cult madness.)

Watching the web/javascript reinvent these 30 year old technologies is a little disheartening but who knows they may come up with something new. (Then again, recently the javascript guys have discovered the enormous value of repeatable builds. Unfortunately the implementations here all pretty much suck.) Still, we ought to perhaps ask ourselves why this situation has come about...

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

#484

Post by joeax » Tue, Jul 10, 2018, 11:18 PM UTC

hinkley wrote: post #7

alexrbarlow wrote: post #2

I'm not sure what they've been left with is a monolith after all. I would say they just have a new service, which is the size of what they should have originally attempted before splitting. In particular, as to their original problem, the shared library seems to be the main source of pain and that isn't technically solved by a monolith, along with not following the basic rule of services "put together first, split la…

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.

At this point you're over-granularizing your services into nanoservices, which is an anti-pattern.

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

#485

Post by vajrabum » Tue, Jul 10, 2018, 11:18 PM UTC

marcosdumay wrote: post #439

tabtab wrote: post #380

Earlier quoted context omitted.

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…

> proving nested blocks were objectively better than go-to's Dijkstra spent many, many pages on that. And it's still not a clear cut "this one is always better" case, as there are some obvious exceptions.

If you'd ever had to support some old Fortran or Cobol littered with gotos you'd probably sing a different tune. I'd guess you've never seen that sort of mess though. It's gotten pretty rare.

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

#486

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

johndubchak wrote: post #235

ljm wrote: 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…

> ... the fundamental problem was centered around a shared architecture of destinations and shared code.

From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism.

The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro services are usually not old enough to have experienced the pain in a different context.

Should shared libraries be in different repos, or should you put everything in a single repo? How do you deal with versioning? What happens if one app wants version 1 of the library and another app wants version 2? How do you deal with backwards compatibility of the API? Do you make a whole new library when you decide the old API is incompatible with the new vision? Blah, blah, blah, blah. None of this is a new problem.

I can't remember which version of Windows it was (maybe 7?) where they were seriously delayed mainly because they had so many programs using different versions of libraries. Integrating it at the end was apparently complete hell. Since they wanted to have separation of responsibility in their groups, each group was just pounding away implementing the features that they needed, but not integrating as they went -- because that would mean lots of cross team communication. The exact same thing is likely in a large organisation with a ton of micro services.

There isn't just one way to solve the problem. Mono repos and monoliths help in certain ways and cause problems in other ways. There are other techniques as well (should we implement ld.so for micro services? :-) ) But as you mention, the real answer is that the solution requires humans, not technology.

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

#487

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

bsder wrote: post #466

thermodynthrway wrote: post #391

Earlier quoted context omitted.

I've worked on a system that used Kafka in-between. It makes consistency issues a ton worse because everything is async. At least with HTTP you can do synchronous calls

Repeat after me: there is no such thing as a synchronous network. I get where you are coming from. But you will go async sooner or later if you need any reasonable error recovery or reliability. The only question is how much pain you will suffer before you do so.

This is just not true. Google uses almost entirely immediately consistent databases and gRPC internally. Eventual consistency is hardly ever required for REST type calls even at massive scale.

gRPC has no queuing and the connection is held open until the call returns. All of Google's cloud databases are immediately consistent for most operations

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

#488

Post by spraak » Tue, Jul 10, 2018, 11:35 PM UTC

asdsa5325 wrote: post #293

spraak wrote: post #263

Earlier quoted context omitted.

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

badlanguage/ is too long

Such a tired view/joke. Python is just as bad but doesn't receive nearly as much hate

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

#489

Post by 52-6F-62 » Tue, Jul 10, 2018, 11:39 PM UTC

Deadron wrote: post #451

52-6F-62 wrote: post #266

Earlier quoted context omitted.

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

Sounds like a "right tool for the job" situation.

I thankfully don't have to worry about power loss (large company, teams dedicated to critical systems infrastructure in a big way), and a cron job can handle any archival concerns in the projects I'm running here.

It does sound like they've improved much since 2011.

Anyway thanks for the insight

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

#490

Post by philippz » Tue, Jul 10, 2018, 11:40 PM UTC

This is what we did at STOMT at day one. For those who are interested in how to accomplish this with PHP / Laravel / Lumen: https://www.stomt.com/blog/shared-components-across-multiple...