631–640 of 782 posts
Going back from 100+ microservice to 1 monolith is another extreme to me...Perhaps you can have 10 macroservices. And shared library shouldn't contain business logic...
What's the point then? They become libraries then, not services.
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 c…
I must agree. Seems like every step could have been solved without jumping to the conclusion that it was because we didn't use a monolith. I've never understood the false dichotomy of microservices vs monolith... just split things when it makes sense. ¯\_(ツ)_/¯
Earlier quoted context omitted.
There is commonality across those 140 services that they extracted into a shared library so they weren’t copying that commonality 140 times.
The fix, then, is to put that commonality into a new microservice the other microservices call. The more I read about the problems people have with microservices, the more I'm convinced they've never read about flow-based programming.
If you have two different teams collaborating or you expand beyond what a single box can do, create services. But if you can express things reasonably as a single service, why make things more complicated and error prone?
"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...
Earlier quoted context omitted.
The most telling fact is that it "took milliseconds to complete running the tests for all 140+ of our destinations". I've never worked on a single service whose tests ran that fast, given that the time spent by the overhead of the test framework and any other one-time initialization can take a few seconds just itself. It's great to have tests that run fast, but that's a bit ridiculous. Some rules of thumb I just came…
> never worked on a single service whose tests ran that fast I'd say you've never had good tests. I have a test-suite for a bunch of my frameworks that dates to the mid 90s, with tests added regularly with new functionality. It currently takes 4 seconds total for 6 separate frameworks and 1000 individual tests. Which is actually a bit slower than it should be, it used to take around 1-2 seconds, so might have to dig…
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…
Wow. This is the level of discourse we've reached here now.
Why the ad hominem? If you have an actual point to make on technical merit, by all means, make it. Were you passed on in a job interview at Segment? Why the hostility? (honest question)
How independent do you want your services to be?
How well your code is organized? Mono repo or multiple repositories?
How much operational complexity can your team handle?
Do you have a Continuous Delivery platform in place?
How is your team organized? Do they have knowledge about different toolsets and microservices architecture?
Then focus on the existing case studies like this and make an architectural strategy.
Earlier quoted context omitted.
I must agree. Seems like every step could have been solved without jumping to the conclusion that it was because we didn't use a monolith. I've never understood the false dichotomy of microservices vs monolith... just split things when it makes sense. ¯\_(ツ)_/¯
"when it makes sense" isn't a science though; for them it made sense at the time, like how now it makes sense to move back to a monolith.
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
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.