Hacker News Reader

Comment by jdavis703 | Hacker News Reader

It's easier to just start over again with one small part. I've worked at two places with massive monolithic tech debt ridden codebases. It was nearly impossible to rewrite anything because everything touched everything. Now the place I currently work has micro services. Some are legacy tech debt that no one wants to touch. But if needed they could probably be rewritten in a couple of months. It's the difference between selling AAA bonds and junk bonds. You're probably far more likely to pay off those low interest AAA ones than the junk bonds.

View on HN

The tradeoff though is that you can't get a handle on how expensive a particular call is because the domino effect of knock-on calls is very difficult to see. You can get a system that 'works' on test data but doesn't scale to production (from a user's perspective, this code doesn't work, even though the dev team will insist that it does)

Engineering is about trade offs. Microservices are a fairly recent innovation, and there are many kinks that need to be worked out. Another issue is the overhead cost of maintaining a large number of decoupled, independent services. It's plausible to have hundreds or thousands of microservices, and the tools to visualize/manage these systems haven't yet been created.

> Microservices are a fairly recent innovation

Yeah, no. Micro-services are neither recent, nor innovative.

Fun fact: a friend of my consults for large pensions funds in The Netherlands. One of the projects he was brought in on earlier this year to get an outside perspective on was this gigantic monument to micro-services that had been built up over a two year period by ~200 developers, at a cost of around 50 million euros.

After two months, every developer was fired, the project cancelled, and the entire 50 million euro cost written off.

But it had great micro-services, hundreds and hundreds of them!

Correct. Microservices are a fundamental tenant of how Unix pipelines. They go back (at least) to the 70s. Source: https://articles.microservices.com/the-origins-of-microservi...

they are to the kids who make web apps - most of this stuff they talk about on the internet is by kids who make web pages for start ups. I used to rant and say similar things, I now see the value of peer reviewed material. Basically 90% of developers advocating things on the internet are not peers, I look for how many projects they've developed successfully in the new gee whiz tech before reading too much. Really most of this stuff was originally thought of in the 70's and 80's, we just keep going in circles.

I'm often in the minority opinion so I'm used to it, but to me microservices aren't fundamentally different than the message passing systems which we've tried many times. But when something doesn't work we try the opposite of it instead of just less or more. Monolithic server got you down? MICROSERVICES. Microservices got you down? Put everything into one process space!

Uh, how about we put all of the related stuff together so we have 8 services instead of 800? Could we maybe try that? How about something really crazy, why don't we give Conway's Law a try and arrange our code around organizational boundaries or vice versa?

Tell me about it. The problem is moving parts. Whether you spread it out over several programs or not does not matter. If you manage to really decouple programs so they can do useful work independently of one another then that's great. Congratulations to you. But microservices can just as easily turn into one huge program separated into many small ones, none of which make any sense on its own, and now all you've done is make things harder for devops.

I heard a phrase a couple months ago that I believe sums this up. What you want is local reasoning. You need to be able to estimate the scope of consequences of a change so you can act accordingly. You also need to be able to look at a problem and estimate the scope of code that could be causing the problem.

We have a bunch of rules and guidelines that work toward that goal but if you don't know the destination you may never arrive.

Reply on news.ycombinator.com