Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Monolithic applications with a product owner with a strong commitment to its scope, translating into an application with a definite scope, is a good thing. My experience has been with monolithic applications that are open ended and end up doing whatever the business needs. They are the classic big ball of mud, with all the accompanying problems.
The issue is perhaps far deeper than just microservices, rather a direction that software has taken which encourages domain binding early. Rather than asking what broad capabilities are needed and how they can be met we have seen narrow domain coupled applications which are fragile, brittle and inflexible.
Monolithic applications with a product owner with a strong commitment to its scope, translating into an application with a definite scope, is a good thing. My experience has been with monolithic applications that are open ended and end up doing whatever the business needs. They are the classic big ball of mud, with all the accompanying problems.
laputan.org/mud/
The issue is perhaps far deeper than just microservices, rather a direction that software has taken which encourages domain binding early. Rather than asking what broad capabilities are needed and how they can be met we have seen narrow domain coupled applications which are fragile, brittle and inflexible.
Touche. Monoliths can also be bad. My point was just that they're not a historical oddity. They're still common.