Interestingly my experience is the exact opposite. The previous2 company I worked for collapsed, largely (IMO) due to an excessively microservice style that massively slowed development. Whereas successful projects I’ve worked on have used disciplined encapsulation (which in fairness we did enforce - multiple maven modules so that one service can only call another via their public interfaces, even though all services are deployed as a single application).
Could you elaborate more? What could have been done to prevent the collapse? Why did it slow development, was it too much coupling across services, too much sharing, too little? Maybe your services were split where they should’ve been together, or vice versa? I’m using such a style at work now, and I’d very much like to know what signs your saw. Also, by collapse do you mean run out of money or the project was just shut down?
It just introduced too much overhead for development, particularly for debugging; problems were much harder to track down than in more monolithic applications I’ve worked on. Having to wait for service discovery when you restarted things made the development feedback cycle much longer. The difficulty was obvious to all developers (just ignored by those in charge), so if you’re not seeing problems then you’re probably not having the same issues I did. The company ran out of money, made all the developers redundant and went back to using the previous version of the system.
Interestingly my experience is the exact opposite. The previous2 company I worked for collapsed, largely (IMO) due to an excessively microservice style that massively slowed development. Whereas successful projects I’ve worked on have used disciplined encapsulation (which in fairness we did enforce - multiple maven modules so that one service can only call another via their public interfaces, even though all services are deployed as a single application).
Could you elaborate more? What could have been done to prevent the collapse? Why did it slow development, was it too much coupling across services, too much sharing, too little? Maybe your services were split where they should’ve been together, or vice versa? I’m using such a style at work now, and I’d very much like to know what signs your saw. Also, by collapse do you mean run out of money or the project was just shut down?
It just introduced too much overhead for development, particularly for debugging; problems were much harder to track down than in more monolithic applications I’ve worked on. Having to wait for service discovery when you restarted things made the development feedback cycle much longer. The difficulty was obvious to all developers (just ignored by those in charge), so if you’re not seeing problems then you’re probably not having the same issues I did. The company ran out of money, made all the developers redundant and went back to using the previous version of the system.
I agree with the author. If nothing else, it stops lazy/good developers and bad developers alike from taking bad shortcuts.