> This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.
Its not purely a skillset issue. Its a domain discovery issue, which Fowler mentioned as boundary discovery. Most startups are inventing their own domain in whole or in part; as the business changes, either the "domain" changes with it, they segment and focus their efforts on part of the domain, or they invent a new set of domain concepts. Evolving an application is often difficult when everything is Just Right. When its not, and you throw into the mix artificial boundaries that have arisen from incomplete, incorrect, or evolving analysis, the job is going to become much, much harder.
You are saying that you cannot have an architecturally sound software system when you do not fully know your domain. This is a fallacy. In fact, architectural soundness makes it MUCH easier (tractable) to grow your system in the face of changing your domain.
How is it easier to change a service interface than an API within a single app? The former requires a specification and tooling around serialization/deserialization to have any meaningful guarantee of correctness, it requires error handling to reap the benefits of decoupling, the latter can be covered with a unit test.
I'm sorry but this is pure hype to say that microservices make refactoring easier: that is true if and only if your boundaries stay static. It is a huge assumption that anyone can draw those boundaries correctly for a large microservices architecture in its infancy.
That's not what I'm saying at all. You seem to be jumping to an assumption that all architectures are created equally at all points along the knowledge graph, or alternatively that a microservice architecture is fundamentally better than a monolithic architecture, and neither interpretation of that is true.
Its not purely a skillset issue. Its a domain discovery issue, which Fowler mentioned as boundary discovery. Most startups are inventing their own domain in whole or in part; as the business changes, either the "domain" changes with it, they segment and focus their efforts on part of the domain, or they invent a new set of domain concepts. Evolving an application is often difficult when everything is Just Right. When its not, and you throw into the mix artificial boundaries that have arisen from incomplete, incorrect, or evolving analysis, the job is going to become much, much harder.