"microservices is the architecture du jour"
? There is nothing new about microservices. They've been a hot topic for far longer than Segment has been an idea.
Goodbye Microservices: From 100s of problem children to 1 superstar
111–120 of 782 posts
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#112Microservices 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…
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#113Earlier 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…
With web apps the main concern is data consistency between relations. On the OS level you have these same concerns with memory and disk, and there's database-like systems in the kernel and drivers to handle it. Essentially all these utilities are running within the same "database" which is disk and memory management handled by the kernel. Usually microservices have their own databases, which is where consistency hell…
> Usually microservices have their own databases
That's news to me, and seems insane.
Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#114Too 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…
Why does a dumb website need a product manager?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#115I'm hardly a microservice apologist, but sharing code or data across services is a major smell. It means these things are related, and should likely be bundled together. Don't just break a service apart because it's de rigueur.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#116Earlier quoted context omitted.
The reality is that since the days of the social contract between employer and employee are long gone - i.e. I show a company loyalty and they will keep me at least at market rates and not lay me off to “increase shareholder value. Developers have to use the new and shiny to keep themselves marketable and be ready to jump ship at the first opportunity or out of necessity.
How frequently are developers being laid off? And why should companies just keep people around if they aren’t adding value? The lack of that “social contract” has resulted in much higher wages. Look at developer salaries in Paris compared to New York. Since there is more job security in France, the trade off is that “market rates” are dramatically lower.
I’m not saying that the lack of a social contract for developers is bad. I’m just saying it is a thing. But if you’re wondering why developers always want to do the new and shiny even if the underlying product is boring, they are probably doing resume driven development and looking at thier next opportunity.
My salary has gone up by $45K - $50K in the last 4 years by changing jobs three times. I’m not complaining.
But on the companys’ side, it was completely illogical not to pay me market rates. They still had to pay my replacement market rates and they loss institutional knowledge when I left.
Why is it that HR will approve a req for a new developer at market rates but have strict limits on what they can pay current employees.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#117Microservices 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,…
That doesn't really say anything though: "Things were bad, and it felt out of control, because of microservices. They didn't work, and actually made things worse and more complex. The things that were supposed to be good were bad. We didn't do good work, we did bad work, and slowly."
How do you address something like that coherently? I sort of agree with the OP, it kinda sounds like they just didn't know what they were doing. Or maybe that quote wasn't really the meat of their complaint?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#118I'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…
unless they have 100 developers for 100 services. That cure is worse than the disease. Every service works differently and 80% of them are just wrong, and there’s nothing you can do because Tim owns that bit.
How does the service architecture affect that? Tim could be as protective of a code file as he is of a service. At least with a service you could work around it.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#119Microservices 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…
I don't they think are worse than anyone else. It takes courage to write about failures and micro services are a complex thing to get right.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#120I'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…
The key to a large code base is a hierarchical design. People are looking for a technical solution to a design problem. No matter what technology you use if you don't maintain the hierarchical layers your code will turn to mush. Micro services can provide a really strict boundary but if you draw the line in the sand at the wrong place it isn't going to matter.