This is part of the reason microservices are becoming reasonably popular. They facilitate scaling people. If you think about it one of the biggest projects we have, the military, scales through assembling near-identical pieces structurally (but not functionally, an artillery unit has a totally different role to an infantry unit).
Microservices may help scaling but tend to come with a fixed amount of overhead which makes them more effort at a very low and low scale. They are also perfect as long as you got the overall architecture right and do not have to make cross-cutting changes because this turns a coordinating people in a team to coordinating people across teams problem.
Yes! Ironically, microservice architectures replicate the same set of advantages and challenges you have scaling teams. The abstractions (team / process boundaries) become much more rigid. But in exchange, within a team / service, change becomes easier because there's less to understand and navigate.
How well the whole system functions depends deeply on how well those abstractions map the solution space. When you're doing something routine (eg most web development), lots of people have figured out reasonable ways of breaking the problem down already. So it works pretty well and you don't carry much risk that the abstractions you pick from the start will hurt you down the road. But when you're doing something more creative and exploratory - like a marketplace for VR, or making a new web browser or making something like Uber - well, then you take on abstraction risk. You will probably make mistakes in how you initially break up your teams and services. Executing well depends on your organizational ability to learn and refactor.
I disagree to an extent. Very few solutions are scalable across an entire range of a problem space.
Something being scalable, to me, means that it can cover a _broad_ range of the problem space, but doesn't imply it covers 100% of it.
If we imagine that the "problem space" is managing software projects from 1 person up through 1,000,000 people and you told me that there was a solution that worked for the range of 50-1,000,000 people I would describe it as scalable, even if I wouldn't recommend it to a 5 person team.
Great point! Actually "scalable" in any direction is meaningless until you provide the scale, performance, reliability, cost and time requirements you have to consider while scaling. A single server for a typical web workload is just fine, if you don't need to be up more than ~ 99,9% of time, if you don't have more than 10s of thousands of users. Considering the availability, you could e.g. reboot into a smaller or larger VM. (I know, this is crazy to write on HN but a single virtual server is plenty reliable for most things if you are able to do a very fast recovery from backup to limit the extent of a disaster.) :-) If you don't consider "serverless", it really doesn't get much better than a single server considering cost. If you want more reliability/ availability and more performance, you probably have to take other approaches. E.g. more servers, services like S3/ lambda, maybe a mainframe (cluster) in certain situations etc.
And predicting cross-cutting concerns is at least as difficult as predicting all of your business changes, which is at least as difficult as predicting the future.
I see it differently. In my experience with 200+ devs, Microservices itself is a buzzword to a certain extend and allows for different team to avoid talking to each other: they build their "own" services, which are copies which leads to bloat.
I think you have to align incentives and the contractual level. For example, don’t pay by the hour, Pay for an API. Mandate that it’s documented in a machine-readable way. Require it to integrate with your centralized authentication and logging services. Mandate thorough, human-friendly documentation Programmatically validate as much of this as possible, add periodic human review (ie surveys, interviews).
The goal is to treat each team as a vendor for their service. You hold them accountable for the product and pay them for outcomes.
This, but typically a team of 20 has 1 monolith, afterwards team of 20 has 8 microservices. Equivalent of one battle squad now has to learn a bit of tanking, learn a bit of flying etc.
