5 ms·

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 stu

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 sources of technical debt. This isn’t an article about how microservices architecture is somehow bad, it’s an article about how bad Segment’s engineering team is. You can make the same argument for anything. At the end of the day some architecture or process or programming language or tech can’t replace real thinking about your problem and correct application.

halayli 8y ago
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.
- WaxProlix 8y ago
  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?
- fastball 8y ago
  iamleppert does address that. As they said, microservices are supposed to mirror the structure of your team(s). A single team should never be maintaining 140 different microservices. That's not a failing of the microservices architecture, that is a failing of massively abusing the microservices architecture. Arguably, a small team should never be managing more than 10 services (totally arbitrary number, but it seems like the upper limit to what a human can focus on).
- sulam 8y ago
  The important part here, that the parent addressed, is the statement "small team", as an organizational structure distinct from, say, a "large team" which has the opportunity to experience Conway's law. It sounds like Segment very much prematurely optimized. Microservices is probably not a great approach below 20 developers, and becomes necessary past 100, at least in my experience.
- maccam94 8y ago
  They used microservices to paper over poor testing hygiene and software architecture. Forking one service into a bunch of different flavors of the same service multiplied the maintenance complexity. Services/microservices that are tightly coupled to shared libraries with lots of surface area are an anti-pattern. Instead, I would make the shared libraries into a service, and make a standard interface for the destinations as plugins.
noobtubepython 8y ago
https://en.wikipedia.org/wiki/List_of_burn_centers_in_the_United_States https://en.wikipedia.org/wiki/List_of_burn_centers_in_the_Un...
some_account 8y ago
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.
- tclancy 8y ago
  It would be fascinating to see this posted 6 months from now but with a man's name and picture on the byline and see if the comments are so negative.
  - quickthrower2 8y ago
    I doubt it would make any difference.
otterley 8y ago
As a principal engineer at Segment with over 20 years’ experience at successful companies large and small, I can personally attest to the fact that our team is incredibly talented and thoughtful. We make our engineering decisions very carefully and are highly evidence driven. Our choices are highly pragmatic and we investigate and analyze the trade-offs whenever we make a significant change such as this. I’m proud of what we’re doing. You can quibble with our implementations, but at the end of the day, the proof of the engineering is in the working. Our system works even better than before and our customers appreciate it!
- deleted 8y ago
  [deleted]
- stanmancan 8y ago
  OP can correct me if I'm wrong, but I believe the comment around Segements engineering team was most likely referencing the original decision to create hundreds of microservices in the first place.
collinvandyck76 8y ago
> it’s an article about how bad Segment’s engineering team is That's totally unnecessary and reflects poorly on you for having said so.
fipple 8y ago
Yes, this awful engineering team built an incredibly successful company/product. I wish I was as awful as them.
- stanmancan 8y ago
  Not here to comment on Segments engineering prowness, I have no clue one way or another. However; I think an overwhelming number of engineers and developers are mislead in believing that you have to have the perfectly crafted program/service/app/whatever in order for it to be successful. It doesn't! Your tech stack has next to no impact on the success of your product. Making something useful is really all that matters. Is the service running? Great, that's all the end user cares about. The back end could be a bunch of code copy-pasted off old form posts from 1998 and string together with scotch tape as long as it works. The end user doesn't care about what language you use. They don't care if you use redis, mysql, postgres, or mssql 2000. They don't care if the HTML or CSS is messy. They won't judge you if you don't use SASS or LESS or whatever is popular today. The most successful side project of mine runs on a $20/m VPS and has been re-written 3 times and the code has been pretty terrible every time because every re-write was done in a new language I learnt over a weekend and never touched again. The first was some horrible PHP, then some less horrible PHP, then GO, and recently someone re-write it (properly) in elixir. The end user doesn't know, the end user doesn't care. The site gets about 250K uniques a month and the API handles about 350 million requests a month. The crappy GO I wrote in a weekend worked just the same for the end user as the fancy elixir. Anyways, sorry for the rant. I've just seen so much wasted effort go on projects that never launch because people are too concerned about stuff that really doesn't matter in the long run. If your stuff runs like crap because it found a market fit and you have people signing up and your crappy code can't handle it, then that is a FANTASTIC problem you now get to solve.
modarts 8y ago
> This isn’t an article about how microservices architecture is somehow bad, it’s an article about how bad Segment’s engineering team is. 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)

halayli 8y ago

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.

WaxProlix 8y ago
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?
fastball 8y ago
iamleppert does address that. As they said, microservices are supposed to mirror the structure of your team(s). A single team should never be maintaining 140 different microservices. That's not a failing of the microservices architecture, that is a failing of massively abusing the microservices architecture. Arguably, a small team should never be managing more than 10 services (totally arbitrary number, but it seems like the upper limit to what a human can focus on).
sulam 8y ago
The important part here, that the parent addressed, is the statement "small team", as an organizational structure distinct from, say, a "large team" which has the opportunity to experience Conway's law. It sounds like Segment very much prematurely optimized. Microservices is probably not a great approach below 20 developers, and becomes necessary past 100, at least in my experience.
maccam94 8y ago
They used microservices to paper over poor testing hygiene and software architecture. Forking one service into a bunch of different flavors of the same service multiplied the maintenance complexity. Services/microservices that are tightly coupled to shared libraries with lots of surface area are an anti-pattern. Instead, I would make the shared libraries into a service, and make a standard interface for the destinations as plugins.

noobtubepython 8y ago

https://en.wikipedia.org/wiki/List_of_burn_centers_in_the_United_States https://en.wikipedia.org/wiki/List_of_burn_centers_in_the_Un...

some_account 8y ago

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.

tclancy 8y ago
It would be fascinating to see this posted 6 months from now but with a man's name and picture on the byline and see if the comments are so negative.
- quickthrower2 8y ago
  I doubt it would make any difference.

otterley 8y ago

As a principal engineer at Segment with over 20 years’ experience at successful companies large and small, I can personally attest to the fact that our team is incredibly talented and thoughtful. We make our engineering decisions very carefully and are highly evidence driven. Our choices are highly pragmatic and we investigate and analyze the trade-offs whenever we make a significant change such as this. I’m proud of what we’re doing. You can quibble with our implementations, but at the end of the day, the proof of the engineering is in the working. Our system works even better than before and our customers appreciate it!

deleted 8y ago
[deleted]
stanmancan 8y ago
OP can correct me if I'm wrong, but I believe the comment around Segements engineering team was most likely referencing the original decision to create hundreds of microservices in the first place.

collinvandyck76 8y ago

> it’s an article about how bad Segment’s engineering team is That's totally unnecessary and reflects poorly on you for having said so.

fipple 8y ago

Yes, this awful engineering team built an incredibly successful company/product. I wish I was as awful as them.

stanmancan 8y ago
Not here to comment on Segments engineering prowness, I have no clue one way or another. However; I think an overwhelming number of engineers and developers are mislead in believing that you have to have the perfectly crafted program/service/app/whatever in order for it to be successful. It doesn't! Your tech stack has next to no impact on the success of your product. Making something useful is really all that matters. Is the service running? Great, that's all the end user cares about. The back end could be a bunch of code copy-pasted off old form posts from 1998 and string together with scotch tape as long as it works. The end user doesn't care about what language you use. They don't care if you use redis, mysql, postgres, or mssql 2000. They don't care if the HTML or CSS is messy. They won't judge you if you don't use SASS or LESS or whatever is popular today. The most successful side project of mine runs on a $20/m VPS and has been re-written 3 times and the code has been pretty terrible every time because every re-write was done in a new language I learnt over a weekend and never touched again. The first was some horrible PHP, then some less horrible PHP, then GO, and recently someone re-write it (properly) in elixir. The end user doesn't know, the end user doesn't care. The site gets about 250K uniques a month and the API handles about 350 million requests a month. The crappy GO I wrote in a weekend worked just the same for the end user as the fancy elixir. Anyways, sorry for the rant. I've just seen so much wasted effort go on projects that never launch because people are too concerned about stuff that really doesn't matter in the long run. If your stuff runs like crap because it found a market fit and you have people signing up and your crappy code can't handle it, then that is a FANTASTIC problem you now get to solve.

modarts 8y ago

> This isn’t an article about how microservices architecture is somehow bad, it’s an article about how bad Segment’s engineering team is. 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)