This content originally appeared on Level Up Coding - Medium and was authored by Vadym Barylo
My brave country Ukraine is fighting with russian terrorists exactly now when you are reading this post. Everyone can help with donations to the supporting funds and by bringing attention to the biggest war in Europe in 21 century. Don’t be silent.
The thirst for new knowledge and valuable achievements often stimulates us to adopt new, hot and trendy technologies in our current business. Again, the thirst for new achievements often is a driver for changes, but not a business need.
Obviously, the risk is a noble cause, so even the intent to play with new technologies brings useful gifts in skillful hands and builds a good foundation for further transformational changes: curiosity, demand for collective upgrades, and self-improvement. These collective qualities are hard to support in a company with a conservative mindset, with a conservative management type.
And, in general — if we consider ourselves as agile followers — the technological, procedural, and organizational changes are a foundation for evolution. Static, inertia, and long-term planning are the characteristics of the anti-patterns for modern systems. Ready to adopt changes, flexible for business vector change, painless correction, and more effective reaction to short-term challenges is a preferable evolutional pattern for the modern company.
But there are also inevitable changes. The changes have to occur because some conditions are met. And often we just postpone the inevitable or resist it. It is like going up the escalator that is moving in the opposite direction — if you stop you will move back, but putting effort more than needed will give you some positive speed. But choosing the right side of the escalator helps us move without effort at all, and any additional force just increases this speed.
Choosing the right architecture pattern is more about choosing the right escalator side. Either we spend efforts to keep any non-negative speed or we move by default and use our efforts to be even more productive in required periods.
“Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.”
This compelling force (escalator direction in the previous metaphor) is Conway’s law which predicts that eventually system architecture will reflect team topology, or more precisely — will reflect communication patterns between teams that are involved in design and development.
The law predicts, that product architecture produced by a single big team, eventually, will include a lot of characteristics from the monolith project (even having the solution be represented as a set of separate independent services). This can be reflected not only in particular service designs but also in delivery or deployment specifics, as well as using common modules for all existing sub-systems, common security layers or monolith application upgrades, etc.
So “escalator in wrong direction” in this case means that the current model requires permanent efforts to keep the solution to be “microservices like”. At the same time, any “microservices native” features like canary deployment become challenges despite their nativeness to the current architecture. Such “native” features just increase the system entropy instead of making it more reliable.
At the same time, Conway’s law also works in another direction — the architecture of the system creates the force, the stimulus, to transform the team to change the organization's topology to support such architecture.
Having a macro-service or monolith architecture model in place, eventually, small teams responsible for modules or layers will constrainedly connect into bigger units, squats, or other organizational elements. And again, the evidence of such connections is not always a topological change, but an increased number of scrum-of-scrums meetings or common retrospectives between many teams, restructured on-call process, incidents or post-mortem reviews, etc. Again, the demand for reliability (reduction of system entropy) is a transformational stimulus.
In summary, the choice of the monolith, macro, or microservice architecture is more a choice of communication topology inside an organization or department that is designing this architecture. Maybe the reason that small teams often are “overtired” very soon with migration to a microservices architecture exact because of tight coupling between team members. Similarly, big companies tight to replace a single product with a set of connected modules under a single umbrella with an increase in company size and delegation of responsibilities to the lower layer.
After all, is not a surprise that worldwide statistics are demonstrating the trend of increased microservices use with increased department size. On the contrary — small companies demonstrated the opposite trends despite the push from the progressive market.
Therefore, while the world is ruled by small and medium-sized businesses, “true microservices architecture” is more an advertising booklet to hire young progressive engineers than an urgent necessity for a company with small-size departments and no business extremes.
Software architecture is derived from the communications model was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Vadym Barylo
Vadym Barylo | Sciencx (2022-09-30T11:33:36+00:00) Software architecture is derived from the communications model. Retrieved from https://www.scien.cx/2022/09/30/software-architecture-is-derived-from-the-communications-model/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.