3 ms·

There are a lot of truthy ideas here, but I feel like it still subscribes to this rosy picture of avoiding the pitfalls and winding up with an amazing scalable

There are a lot of truthy ideas here, but I feel like it still subscribes to this rosy picture of avoiding the pitfalls and winding up with an amazing scalable architecture that is an unmitigated win and fundamentally better than a monolith. The only problem is that microservices add overhead and require more tuning and control than monoliths. This is especially true if you give teams carte blanche to build things however they want with no shared standards. Being an early stage startup guy I am probably biased, but I would argue it's best to default to a monolith and try to keep things modular with an eye towards later extracting microservices as A) you find incongruent workloads and B) your team is growing and you need to create some isolation so not everyone has to know everything. Only once you understand the problem domain and workloads are you fit to draw service boundaries.

lhnz 10y ago
I agree and will add: it's a good idea to focus on defining or using common and simple protocols and contracts.
ethbro 10y ago
Or to put it another way: There is a time when every feature fits in one team. There is also a time when any given one single feature grows too large for one team. Recognize which time you're in and make the best choice for now (and some of your expected future). If everyone designed everything with the expectation of Facebook levels of traffic, nothing would ever get done (your team isn't big enough), and that overhead would be wasted in 99.9% of cases.