5 ms·

Am I understanding correctly that they had 3 engineers and >140 microservices? Microservices definitely have their own costs and tradeoffs, but 140 services an

by dpark 8y ago

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.

ljm 8y ago
I feel that when it comes to making any decision about separating things out, you really do have to consider the size of the team you've got before you commit to it. If you've got three devs and they all work across all of the microservices, then what on earth do they add except a hell of a lot of overhead? If you had ten teams of seven and they managed two services each... it's easier to see how that architecture could actually help. Same as if you have a two person team building a web-app and they go for client-server architecture rather than a basic full stack web framework. If you're both working the frontend and backend at the same time, save yourself the extra ops effort.
paublyrne 8y ago
I don't think so, the article says there were 3 engineers working just to keep the system up and running. I'm sure there were many more engineers than that working on and with those services.
hobls 8y ago
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 engineers owning something like 2-5 services with a larger ecosystem of dozens to hundreds of services. Of course, I've been working at very large companies with extremely high traffic for several years now, so my experience is skewed in that direction. If I had three engineers on my team I'd be unlikely to end up with more than a small handful of services. Half the benefit of splitting up your services has to do with keeping your independent teams actually independent -- if it's just one team then that isn't a problem in the first place.
- matwood 8y ago
  > 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.
  - hobls 8y ago
    > I doubt any would be considered 'micro', but instead they are designed around functional areas like authentication or backend processing. Yeah, who knows what micro means, but that's exactly how I like to split up services. If at some point a service gets too large, split it up. Hundreds of services out the gate is a gross premature optimization. (And like most premature optimizations, ends up costing much more time both in development and in maintenance.)
dexterdog 8y ago
Look at their about page. If anything it looks to me like they have way too many engineers.
f2prateek 8y ago
At the time we did the split, we had <30 destinations and 3-4 engineers working on this system. At the time we decided to merge, we had > 140 destinations with ~8 engineers, of which roughly 3 full-time engineers spending most of their time just keeping the system alive.
- dpark 8y ago
  How much of the code was shared among these services? It sounds like you essentially had mostly the same code running in 140 different configurations with only some translation logic and glue varying between each. I'm not surprised you found this untenable. This is akin to running a microservice per web page.

by dpark 8y ago

ljm 8y ago

I feel that when it comes to making any decision about separating things out, you really do have to consider the size of the team you've got before you commit to it. If you've got three devs and they all work across all of the microservices, then what on earth do they add except a hell of a lot of overhead? If you had ten teams of seven and they managed two services each... it's easier to see how that architecture could actually help. Same as if you have a two person team building a web-app and they go for client-server architecture rather than a basic full stack web framework. If you're both working the frontend and backend at the same time, save yourself the extra ops effort.

paublyrne 8y ago

I don't think so, the article says there were 3 engineers working just to keep the system up and running. I'm sure there were many more engineers than that working on and with those services.

hobls 8y ago

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 engineers owning something like 2-5 services with a larger ecosystem of dozens to hundreds of services. Of course, I've been working at very large companies with extremely high traffic for several years now, so my experience is skewed in that direction. If I had three engineers on my team I'd be unlikely to end up with more than a small handful of services. Half the benefit of splitting up your services has to do with keeping your independent teams actually independent -- if it's just one team then that isn't a problem in the first place.

matwood 8y ago
> 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.
- hobls 8y ago
  > I doubt any would be considered 'micro', but instead they are designed around functional areas like authentication or backend processing. Yeah, who knows what micro means, but that's exactly how I like to split up services. If at some point a service gets too large, split it up. Hundreds of services out the gate is a gross premature optimization. (And like most premature optimizations, ends up costing much more time both in development and in maintenance.)

dexterdog 8y ago

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

f2prateek 8y ago

At the time we did the split, we had <30 destinations and 3-4 engineers working on this system. At the time we decided to merge, we had > 140 destinations with ~8 engineers, of which roughly 3 full-time engineers spending most of their time just keeping the system alive.

dpark 8y ago
How much of the code was shared among these services? It sounds like you essentially had mostly the same code running in 140 different configurations with only some translation logic and glue varying between each. I'm not surprised you found this untenable. This is akin to running a microservice per web page.