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

191–200 of 782 posts

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

#191

Post by twblalock »

> Our initial microservice architecture worked for a time, solving the immediate performance issues in our pipeline by isolating the destinations from each other. However, we weren’t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined.

Well, I'm not surprised. Microservices are made possible by advances in automated testing, CI, and deployment. You should have those things anyway, even if you have a monolith -- but to go to microservices without them is a pretty bad decision.

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

#192

Post by stefano »

hosh wrote: post #153
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…

Sometimes, I've seen a lack of regard for data consistency within a monolith. That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions. On the other hand, I've seen some pretty flagrant disregard for it just because there are not atomicity guarantees. Microservices makes reasoning on that harder.

> That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions

I'd argue that's on the developer, if he was the one to choose a database that doesn't support transactions, and then didn't implement application-level transactions (which is very hard to do correctly).

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

#193

Post by bartread »

jacquesm wrote: post #36

100's of problem children sounds like a step too far. A few services > monolith monolith > 100's of services. The big trick with any technology is to apply it properly rather than dogmatically and if you are breaking up your monolith into a 100's(!) of microservices you are clearly not in control of your domain. That's a spaghetti of processes and connections between them rather than a spaghetti of code. Just as bad,…

> Just as bad, just in a different way.

Actually worse in many ways:

- Harder to test

- Harder to debug

- Harder to deploy

- Harder to monitor

- Harder to reason about, refactor, change/add functionality

- You've (basically) turned a lot of the operations your services need to perform into RPCs, probably killing performance on top of everything else, leading to

- More complex/demanding (or just MOAR) infrastructure requirements

- Higher dev, maintenance and infrastructure costs

- Slower delivery of value to the business and customers

- Potentially crippling opportunity costs

It surprises me how often people don't see this coming. Seriously: keep your systems as simple as you possibly can. Unless you're Netflix, dozens or hundreds of microservices probably isn't as simple as you possibly can.

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

#194

Post by samsonradu »

johnchristopher wrote: post #178
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…

So, should we stick to PHP for web stuff or is JS here to stay ?

I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work.

The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.

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

#195

Post by lossolo »

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…

Exactly the same thing happened with SQL vs NoSQL.

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

#196

Post by benologist »

johnchristopher wrote: post #178
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…

So, should we stick to PHP for web stuff or is JS here to stay ?

Maybe we could commit to a longer duration with every major change, develop expertise and contribute to improving that solution.

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

#197

Post by dlevine »

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…

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

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

#198

Post by resource0x »

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…

> 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 :)

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

#199

Post by acd »

I have had thinkings on how efficient Micro services are compared to a Monolith.

In a micro service architecture, the request bounces through different service layers, json serialization, network transfers.

In a monthlith normal application, especially if its on one machine, the request touches main memory and then CPU cache.

Latency Numbers Every Programmer Should Know, I especially think of the Send 1K bytes over 1 Gbps network vs cache latency of microservices/monolith. https://gist.github.com/jboner/2841832

Ie instead of micro services 10000 ns for a network transfer you could fetch within 10ns from CPU cache in a monolith, that is 1000 times more efficient.

Are we beyond the peak of inflated expectations on Micro services and towards the Plateau of productivity? https://en.wikipedia.org/wiki/Hype_cycle

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

#200

Post by spyspy »

matwood wrote: post #96
jacquesm wrote: post #36

100's of problem children sounds like a step too far. A few services > monolith monolith > 100's of services. The big trick with any technology is to apply it properly rather than dogmatically and if you are breaking up your monolith into a 100's(!) of microservices you are clearly not in control of your domain. That's a spaghetti of processes and connections between them rather than a spaghetti of code. Just as bad,…

Great point. I like separate services, but would cringe at 100s of services in any system I have seen.

I can't believe this made it out of any planning meetings.

Engineer 1: "We'll have one repo per downstream service."

Engineer 2: "But we have hundreds of those, so now we have to manage hundreds of github repos???"

Anyone sane: "That doesn't sound right, we should rethink this..."

Post reply on HN