True, that is also very funny in my opinion. It's our need to play with new toys that makes us over-engineer stuff.
As I get more experienced, I try to find the easiest, most profound solution to a problem. At the same time I "design" escape scenarios. If that business will scale in that x way then I will be able to do y. Most times the need for scale never comes.
It also depends on the problems you are trying to solve, not only on the Team size.
Let's say you work for a small /medium company and it has a few monoliths. But if more than one needs to manage user authentication and authorization, needs to send mails or SMS, it kind of makes sense to build an user management service and an alerting service.
Yes but bear in mind successful companies do grow and you are then frequently stuck with the startup type choices made early on because "now it's too late" - even if it just due to original small team now being the tech leadership and know no other way. Been at a 30 team company working on an old Rails monolith and it totally sucked.
A well architected monolith isn't necessarily that different from a well architected set of microservices.
The problem with rails is it encourages you to not think about your architecture, and after years of putting every model, controller, or view in literally the same folder, you have a giant pile of shit.
Modularize by feature. And under each feature, you modularize by layer. Slicing your code N ways will scale better with your team than slicing your code 3-4 ways.
But it's not an issue. If you chose tech X because it was the easiest way for the small team to produce an working prototype, when you find success, you might afford to rewrite using tech Y like Twitter switching to Java or alternative approaches like Facebook doing their own PHP version.
It's not like being microservice based and modular from the start will save you from rewrites and architecture rebuilds. Google rewrote parts of their services and modified their architecture hundreds of times. Of course, if the architecture is modular, rewrites and architectural changes are easier.
Yeah, I get that and it happened to me too. That can happen in any design though. Even with a microservices approach.
As I said in the previous comment, you have to design your way out of the thing you are building. Not easy at all, and sometimes, not possible to predict.
I mean successful companies do grow, but a lot of times they pivot, etc.
