This is the best-kept secret of the software engineering profession: engineers
hate code. Especially code written by other people. It's why they love working
on greenfield projects so much. No code, no maintenance, no headaches!
Ever wondered why microservices took off in teams of all sizes? A microservice
architecture is
We only get this if we do microservices correctly.
I’m not sure what point you tried to argue then. I mean, is it a valid starting point to presume the hypothetical monolith is the cleanest software project possible but the same people, when peeling stuff off to another service, suddenly unlearn how to write and manage code?
It sounds like you’re trying to use very weak strawmen to criticize offloading tasks to separate services.
No, I don’t believe that. However, I also don’t believe people who write spaghetti code will start writing better code just because now they are writing smaller components.
For you to argue that, you first need to start from a point where your hypothetical monolith is a tangled mess of spaghetti code similar to the case you tried to pin on microservices. I’m not sure what would be the point of that.
Nevertheless, if you’re arguing over spaghetti code, I’m sure you agree that smaller projects with smaller code bases are easier to untangle than large projects with large code bases. Once you acknowledge that fact, how exactly do you think that limiting the scope of a project wouldn’t improve it’s maintainability? Are we expected to believe that spaghetti code in large complex projects is as easy to maintain as spaghetti code that is a fraction of a size?
As a final note: I’m not saying microservices are bad, or monolith is better than microservices. I’m just trying to introduce some nuance.
Sorry, I don’t think that’s remotely relevant to the discussion. This is about monoliths, and peeling other services out of them. In your example, it would be like dialing up from zero to one or two. Even the source in your quote argues against that, and their point is also not about it. Going too far in microservices does not mean “now the monolith calls a lambda”.
I’m not sure what point you tried to argue then. I mean, is it a valid starting point to presume the hypothetical monolith is the cleanest software project possible but the same people, when peeling stuff off to another service, suddenly unlearn how to write and manage code?
It sounds like you’re trying to use very weak strawmen to criticize offloading tasks to separate services.
For you to argue that, you first need to start from a point where your hypothetical monolith is a tangled mess of spaghetti code similar to the case you tried to pin on microservices. I’m not sure what would be the point of that.
Nevertheless, if you’re arguing over spaghetti code, I’m sure you agree that smaller projects with smaller code bases are easier to untangle than large projects with large code bases. Once you acknowledge that fact, how exactly do you think that limiting the scope of a project wouldn’t improve it’s maintainability? Are we expected to believe that spaghetti code in large complex projects is as easy to maintain as spaghetti code that is a fraction of a size?
Sorry, I don’t think that’s remotely relevant to the discussion. This is about monoliths, and peeling other services out of them. In your example, it would be like dialing up from zero to one or two. Even the source in your quote argues against that, and their point is also not about it. Going too far in microservices does not mean “now the monolith calls a lambda”.