The most important place to put boundaries is where different technology or configurations are necessary for scaling or cost control.
For instance some things work fine with serverless architecture, some things do not.
Some things are CPU limited, other things are memory limited.
The best time to adopt microservices is that time it hits your service costs too much to run and you are counting the days of runway you have left.
You might have one system written in PHP which is 99% ok but the 1% of it which burns 99% of the resources. Write that part in Go, leave the rest alone.
Do not get seduced by the ‘freedom’ to be sloppy, use Guava 7 here and Guava 25 there, have as many ways to start and stop servers as Paul Simon had to leave his lover. Standardize all the little things (anything you would bikeshed) because all those meaningless-but-essential things will destroy your devs unless it easy for them to transfer experience from service X to Y.
Less than 500 lines was a metric I heard once. As I recall it was from an O'Reilly blog interviewing someone, and the interviewer had to practically drag that definition out of the interviewee. YMMV.
For instance some things work fine with serverless architecture, some things do not.
Some things are CPU limited, other things are memory limited.
The best time to adopt microservices is that time it hits your service costs too much to run and you are counting the days of runway you have left.
You might have one system written in PHP which is 99% ok but the 1% of it which burns 99% of the resources. Write that part in Go, leave the rest alone.
Do not get seduced by the ‘freedom’ to be sloppy, use Guava 7 here and Guava 25 there, have as many ways to start and stop servers as Paul Simon had to leave his lover. Standardize all the little things (anything you would bikeshed) because all those meaningless-but-essential things will destroy your devs unless it easy for them to transfer experience from service X to Y.