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

61–70 of 782 posts

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

#61

Post by tomnipotent »

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…

They never said the entire company was left with 1, only than 100s were condensed to "1 superstar".

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

#62

Post by dualogy »

golergka wrote: post #48
tracer4201 wrote: post #29

Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. I was a product manager on a team of really rockstar developers. They all earn at least $200k a year. Instead of demanding more ambitious projects, you could keep about 99% of them happy by just letting them use the new framework of the week to build their next web app. Their excitement when they…

> Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. Because doing something new is much more fun that doing something effective. And most software developers don't really get into this job out of doing things effectively - we're get into it out of the sheer fun of it, altough we would never admit it to our bosses and often even to ourselves.

> Because doing something new is much more fun that doing something effective

Trouble is, "fun" for the enthusiast / self-perceived-non-workdrone does align with "productive". =)

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

#63

Post by Sir_Cmpwn »

Microservices aren't a magic bullet and won't save you from a poorly designed application. You already need to have very good separation of concerns within your application to make it out of microservices, and at that point an API that communicates over HTTP isn't much different from one that communicates over the application stack.

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

#64

Post by ChicagoDave »

I liked the rundown and agree there are tactical benefits for building monolithic API's, but one of the core tenants of microservice architecture coming out of the domain driven design space is that monolithic systems hide business logic. I'm pretty sure by moving everything back to a monolith, you've abandon DDD entirely. From a strategic perspective, that's bad for your business.

If you get your DevOps ducks in order, a lot of the issues you have with standing up and maintaining individual microservices should be manageable. I certainly understand the pain of dependency management, but that's also a part of good architecture.

I'm willing to hear more of these stories though. We can always learn about edge cases or even new paradigms that come out of current thinking.

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

#65

Post by pythonaut_16 »

basejumping wrote: post #47
pythonaut_16 wrote: post #35

Earlier quoted context omitted.

Sounds like you really don't understand development if you think getting to use React isn't a big deal. React (and others like it, e.g. Vue) really is a huge win and solves a ton of pain points common to front end development. It still has its own pain points, but it's hard to overstate how much of an improvement it is over other older approaches like jQuery.

What does react have to do with jquery?

They're both tools used to build interactive websites.

The parent didn't understand why developers would be happy that React got the greenlight. My response was that React (and Vue) really is a much better tool for building interactive websites than many older tools like jQuery.

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

#66

Post by grosjona »

It's refreshing to read an article which challenges common wisdom.

I've endured a lot of suffering at the hands of the microservices fan club. It's good to see reason finally prevail over rhetoric.

It would have been nice if people had written articles like this 2 years ago but unfortunately, people with such good reasoning abilities would probably not have been able to find work back then.

Software development rhetoric is like religion. If you're not on board you will be burned at the stake.

So many times during technical discussions, I had to keep my mouth shut in the name of self-preservation.

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

#68

Post by matwood »

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…

> along with not following the basic rule of services "put together first, split later".

Agreed. I treat services like an amoeba. Let your monolith grow until you see the obvious split points. The first one I typically see is authentication, but YMMV.

Notice I also do not say 'microservices'. I don't care about micro as much as functional grouping.

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

#69

Post by tomnipotent »

athenot wrote: post #4
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…

Agreed. Reading about their setup and comparing with some truly large scale services I work with, I'm left with the idea that Segment's service is roughly the size of one microservice on our end. Perhaps the takeaway is don't go overboard with fragmenting services when they conceptually fulfill the same business role. And regardless of the architecture of the system, there are hard state problems to deal with in asso…

> Segment's service is roughly the size of one microservice on our end.

This gave me a good chuckle. Dunning–Kruger in full effect.

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

#70

Post by ivan_gammel »

eklavya wrote: post #45
dualogy wrote: post #17

Earlier quoted context omitted.

"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…

Except the language argument, don't you get all that by just having modules in your code (assuming a statically typed language since the boundaries are type checked)?

Not really. For example, it's easier to mock a microservice, than a module, for testing purposes. Let's say you have component A and component B, A depends on B (dependency implemented via runtime sync or async call), B is computationally intensive or has certain requirements on resources that make it harder or impossible to test on developer's machine. You may want to test only A: with monolithic architecture you'll have to produce another build of the application, that contains mock of B (or you need something like OSGi for runtime module discovery). When both components are implemented as microservices, you can start a container with mock of B instead of real B.
Post reply on HN