Shai, thank you for taking the time to respond. I very much enjoyed reading When Should we Migrate to Microservices? It is well-written and well thought out. My issue is that the vision of microservices it presents, though the commonly promoted definition of the term, is essentially un-workable.
I do not blame you for that. It is mostly the result of the marketing efforts of companies seeking to exploit the possibilities that real advances in virtualization, containerization/container orchestration, and cloud computing have made more practical. Unfortunately, much of that hype demonstrates a lack of understanding of the real challenges of software development and focuses on peripheral, rather than fundamental, microservices issues.
I got my first job in commercial software development in 1972, after serving as an Army officer in Vietnam. Before that time, the vast majority of commercial software was created by computer vendors as a part of selling their hardware. A US court ruling ended that practice and opened the door for independent software vendors. I got a job with one of them.
I come from a long line of mechanical and aeronautical engineers so I was predisposed to look at software systems as machines and not a creative art form as most programmers then viewed them. My perspective must have worked because I have never blown a project. Within 3 years, I was running a branch of a large software consulting firm and, in 9 years, was running development for the 3rd largest ISV in America.
The single most complex part of developing software is effectively communicating among the many human beings who must define and build the software - and with the people who need and pay for it. The microservice model as commonly described makes that very difficult. In an attempt to formalize meaningful architectural constraints, many of those constraints have been badly thought out and described.
For example, the database per service, schema per service, or table per service patterns don't work for any but the simplest microservice requirements. They don't work because they misunderstand the constraint they are attempting to enforce: "There should be no direct access to a persistent datastore from outside a service. Any and all access to a persistent datastore should be accomplished by invoking a single service specifically implemented to do so."
Each persistent entity should be accessible only through a service specifically created for that purpose and only that purpose. Aggregation is the solution. If another microservice needs to access or modify a persistent entity, it should invoke the microservice specifically implemented for that purpose.
It is obvious that far too many people without practical experience in design, fundamental engineering, and organizing software development projects are pontifcating both pro and con about microservices. I have been making far too much money cleaning up the messes they have created.
A microservice is neither a magical solution to all problems, nor is it a certain path to disaster. At its root it is a tightly-bounded reusable component that responds to an API. It is very vulnerable to the following points of failure:
1 — Its context is too broad. It tries to do too many things, which leads to item 2.
2 — Its API is too complicated, not sufficiently implicit, and easily misunderstood.
3 — Its context is not properly aligned with functional application boundaries, rules, and data ownership, which makes a service hard to develop, test, deploy, and modify without interference with, or from, other development teams.
4 — Its designers and implementers think in terms of traditional SOA services and layered architecture, rather than of independently deployable components and aggregation.
As Fred Brooks said, "the software art always comes down to people". Simple, easy to understand, and appropriate to use cases, architectural patterns that help to mitigate the inevitable friction among development teams are essential to the economical development and iteration of microservice applications.
The goal of software architecture is to minimize the human resources required to build and maintain the required system. One of the ways sound architecture does that is to postpone technical choices for as long as it can.
For example, the author of a microservice should not care about the technology being used to communicate with other microservices, but only whether the invocation is logically synchronous or asynchronous. The actual delivery should be in the infrastructure within which the service operates.
An effective microservice infrastructure should support dynamic configuration and enable seamless failover, scaling, and load balancing for both cloud-based and server-based deployments.
https://medium.com/nerd-for-tech/the-power-of-message-orchestration-b28f18da603a
