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

231–240 of 782 posts

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

#231

Post by [deleted] »

techinformed56 wrote: post #53
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…

+1 I felt this article is more about how to use microservices right way vs butchering the idea. It is not right to characterize this as microservices vs monolith service. Initial version of their attempt went too far by spinning up a service for each destination. This is taking microservices to extreme which caused organizational and maintenance issue once number of destinations increased. I am surprised they did not…

[deleted]

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

#232

Post by wuliwong »

Dirlewanger wrote: post #213
copperx wrote: post #187

Earlier quoted context omitted.

I can't find the right place for Ruby on Rails here. It doesn't fit.

Rails was never really a major leap forward in anything, more so an evolution with convention-over-configuration and a strong community presence that established best practices early. It also hasn't been "cool" for years, it's an entrenched player that "just works". One could argue with all the Rubyists going to Elixir that's part of the cycle, but for many people that's been a net positive. And then there's those al…

I think that Rails using Ruby was a big deal. It was definitely different. Not sure if it was forward, backwards or lateral but it certainly was a big change beyond just "convention of configuration."

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

#233

Post by ris »

I'm not sure how worthwhile it is writing any more "microservices are dumb" articles - all the people who have spent the last 5 years leaving microservice messes in their wake appear to have moved on to creating "serverless" messes of lambda functions which people like you and me are going to be going around tidying up in about 5 years from now.

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

#234

Post by matrix »

copperx wrote: post #190
_ea1k wrote: post #148

Earlier quoted context omitted.

To be blunt, its news to a lot of people, but it also isn't wrong. Microservices really shouldn't share a database, and if they do then they aren't "microservices".

What is that called, then? Having small programs, each responding to a different part of the API, all storing data in a single shared DB?

It's called: a distributed monolith

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

#235

Post by johndubchak »

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

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 that you extract your variant code into your non-shared code. Shared code should evolve at a much slower pace than your non-shared code or you risk this very outcome.

Microservices are not dead, nor are they the solution to everything. We need better architects.

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

#236

Post by jarfil »

The whole article reads like BS to me.

So the initial problem was a single queue? Well, then split the queue, no need to go all crazy splitting all the code.

Switching to 100+ microservices? There is no need to switch to 100+ repos too, runtime services don't need to have one repo per service, just use a modular approach, or even feature flags.

100+ microservices, some of them with much lower load than others? Then consolidate the lower load ones, no need to consolidate "all" of the microservices at once.

Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.

A single change breaks tests in a way you need to fix unrelated code? WTF, don't you have unit tests to ensure service boundary consistency and API contracts?

Little motivation to clean up failing tests? Yeah... you're doing it wrong.

Only then you figure out to record traffic for the tests? HUGE FACEPALM, that's the FIRST thing you should do when dealing with remote services!

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

#237

Post by bpicolo »

jrs95 wrote: post #91
scarface74 wrote: post #81

Earlier quoted context omitted.

Mocking modules for unit testing has been a solved problem for decades in almost every language.

And running an integration test on a single modular application is easy . Doing it for a distributed system is very hard .

Easy until you have 100,000 of them anyway, in which case it's expensive and slow to run it for every dev. (At that point you have enough devs that microservices 100% make sense, though)

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

#238

Post by cpursley »

Dirlewanger wrote: post #213
copperx wrote: post #187

Earlier quoted context omitted.

I can't find the right place for Ruby on Rails here. It doesn't fit.

Rails was never really a major leap forward in anything, more so an evolution with convention-over-configuration and a strong community presence that established best practices early. It also hasn't been "cool" for years, it's an entrenched player that "just works". One could argue with all the Rubyists going to Elixir that's part of the cycle, but for many people that's been a net positive. And then there's those al…

I doubt you'll find many people dropping Elixir for Go...

And Ruby was a major leap forward ~ in productivity.

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

#240

Post by johndubchak »

stcredzero wrote: post #208
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'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech A lot of software is used to control or impose someone's will on others organizationally.

Very well said.
Post reply on HN