4 ms·

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

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.

oblio 6y ago
Well, with the ideal technical leadership, you start off with a monolith and clearly delineate boundaries inside it. Then as the project grows chunks just get carved out. Though real life is much messier.
nly 6y ago
Something that only works for huge sizes isn't scalable by definition. Scalable means it can scale up or down
- kaliszad 6y ago
  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.
- ncallaway 6y ago
  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.
josephg 6y ago
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.
vsareto 6y ago
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.

oblio 6y ago

Well, with the ideal technical leadership, you start off with a monolith and clearly delineate boundaries inside it. Then as the project grows chunks just get carved out. Though real life is much messier.

nly 6y ago

Something that only works for huge sizes isn't scalable by definition. Scalable means it can scale up or down

kaliszad 6y ago
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.
ncallaway 6y ago
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.

josephg 6y ago

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.

vsareto 6y ago

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.