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

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

#101

Post by boramalper » Tue, Jul 10, 2018, 5:57 PM UTC

lmm wrote: post #88

NickBusey wrote: post #72

Earlier quoted context omitted.

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

> If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainability wise? You mean like BSD?

Same with BSD; the userspace programs are not part of the kernel, and developed separately by the same entity.

Busybox is a slightly better example (even though it’s also a userspace program).

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

#102

Post by dexterdog » Tue, Jul 10, 2018, 5:57 PM UTC

dpark wrote: post #20

Am I understanding correctly that they had 3 engineers and >140 microservices? Microservices definitely have their own costs and tradeoffs, but 140 services and 3 engineers sounds like just a terrible engineering choice.

Look at their about page. If anything it looks to me like they have way too many engineers.

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

#103

Post by matwood » Tue, Jul 10, 2018, 5:57 PM UTC

hobls wrote: post #73

dpark wrote: post #20

Am I understanding correctly that they had 3 engineers and >140 microservices? Microservices definitely have their own costs and tradeoffs, but 140 services and 3 engineers sounds like just a terrible engineering choice.

Agreed. "Micro" is a terribly defined term, and it sounds like this team went absolutely nuts in one direction. (And then in response to their problems, went as far back as possible to a single monolith.) This suggests a bit of a lack of nuance in their decision making process to me. I'm not interested in figuring out exactly what the right marketing term for it is, but I've had good experiences with teams of 6-10 en…

> If I had three engineers on my team I'd be unlikely to end up with more than a small handful of services.

We have a small team and have a handful of services. We also have a fully automated CI/CD pipeline. It's worked really well. I doubt any would be considered 'micro', but instead they are designed around functional areas like authentication or backend processing.

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

#104

Post by debt » Tue, Jul 10, 2018, 5:57 PM UTC

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…

This speaks to the general boring middle that hits many successful software projects. There's a point where it's simply about iteratively improving it while keeping it running 99% of the time.

It's unglamorous, monotonous and boring, but it's wildly important to the continued success of the project. Who can blame engineers for not being interested in trudging through the boring middle?

Interestingly sometimes efforts to keep engineers from leaving, like splitting an application into 100's of micro services, can actually undermine the entire business. Kind of fascinating if you think about it.

A person in charge may be so afraid to lose an employee they fail to see that the very efforts to keep them may derail the success of the business.

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

#105

Post by gfodor » Tue, Jul 10, 2018, 5:58 PM UTC

Before you go down the path of splitting your app up into microservices you should grok erlang/BEAM/OTP. Lots of thinking went into its creation that leads to highly reliable real time systems and at the very least some of the ideas can be lifted in informing how to best design things. (But really, you should probably just use it instead.)

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

#106

Post by blablabla123 » Tue, Jul 10, 2018, 5:58 PM UTC

NickBusey wrote: post #72

thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

But there is a big difference. These small targeted programs are invoked in user land, usually by the user. Microservices get invoked directly by the user when debugging is going on. Otherwise they are expected to automagically talk to each other and depending on the abstraction even discovery each other automatically.

Also I can pipe these tools together from the same terminal session, like

  tail -f foo | grep something | awk ...

You don't have that in general with Microservices. Unix tools are Lego, Microservices aren't. They are Domino at best.

Probably one could come up with an abstraction to do Lego with Microservices but we're not there yet.

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

#107

Post by apeace » Tue, Jul 10, 2018, 5:59 PM UTC

NickBusey wrote: post #72

thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

My understanding is that OpenBSD is constructed this way, and I have also heard that their code is well-organized and easy to follow.

There is the "base" system which is the OS itself and common packages (all the ones you mentioned), then there is the "ports" repo which contains many open-source applications with patches to make them work with OpenBSD.

Here is a Github mirror of their repos: https://github.com/openbsd

I think OpenBSD has reaped many of the same advantages described by Segment with their monorepo approach, such as easily being able to add pledge[1] to many ports relatively quickly.

https://www.slideshare.net/GiovanniBechis/pledge-in-openbsd

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

#108

Post by draw_down » Tue, Jul 10, 2018, 5:59 PM UTC

jspash wrote: post #23

framebit wrote: post #15

"2020 prediction: Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications." -Kelsey Hightower on Twitter https://twitter.com/kelseyhightower/status/94025989833123840...

I'm waiting for the day that this becomes a standard refrain: "Javascript. What were we thinking?!"

Love when you guys manage to work in a dig at JavaScript while discussing a completely unrelated topic!!!

Bet you think PHP is sometimes the best tool for the job and that people shouldn't be so quick to dismiss it, too. ;)

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

#109

Post by halayli » Tue, Jul 10, 2018, 5:59 PM UTC

iamleppert wrote: post #75

Microservices are an organizational and design choice that is intended to mirror the structure of the teams or engineers, the actual human beings doing this stuff. It seems like Segment didn’t really understand this at all, and instead decided to have seemingly arbitrary and rediculous service boundaries that had no relationship to the real world. See also people who create poor abstractions in their code and other s…

Nothing you said addresses the issues they mentioned:

> In early 2017 we reached a tipping point with a core piece of Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded.

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

#110

Post by ThJ » Tue, Jul 10, 2018, 5:59 PM UTC

stickfigure wrote: post #40

davidkellis wrote: post #5

Earlier quoted context omitted.

> You push data consistency concerns out of the database and between service boundaries. Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data…

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…

When I was designing a microservices architecture for a former employee, the justification for it was security. We needed separation of the components in the system because we were going to be handling money. It used ZeroMQ for communication, because I wanted something more lightweight and falut-resistant for message passing (in such a sensitive application, we didn't want to trust the network). Although it was of course fun to design, microservices weren't my first choice. It just made sense to us to use it in that particular scenario.