4 ms·
But this is a problem at large scale. Each language and stack carries a variety of overhead. The more of them you have, the higher the overhead is. Say you run
by throwawaaarrgh 5y ago
But this is a problem at large scale. Each language and stack carries a variety of overhead. The more of them you have, the higher the overhead is.
Say you run a factory, and everyone needs a hammer. When there's only two teams, two kinds of hammer is fine. But fast forward to 10 teams. Can you always get all of those hammers when you need them? What if team #3 needs extra support? You need to find a new engineer who knows hammer #3, or take an engineer off of team #6 and train them on how to use hammer #3. And if all the hammers need a slight modification specific to that company, you need to make 10 different modifications. And how will all the teams benefit from shared hammer tips-n-tricks if they all use different hammers? There's a lot more overhead than you think at first.
- erik_seaberg 5y agoI don’t care what brand of chainsaw I may use, but we’re going to have trouble hiring and retaining chainsaw experts if our staff is only allowed steak knives (which is what other teams are familiar with).
- adjkant 5y agoIt's a problem if you assume that your infrastructure needs won't scale. For many of the positives listed upthread, it can be a worthwhile trade to heavily invest in infrastructure. It just needs to be a conscious choice, and it also does more or less eliminate any small or even medium sized companies from making microservives work best. Unless you can afford to have an infra team bigger than multiple of your product feature teams, you're not at the point of needing microservices probably.