Consequences of the monolith architect

Ha Doan
2 min readNov 19, 2019

Notes from book: The Tao of Microservices!

  1. All members of the software development team must carefully coordinate their activities so as not to block each other. There’s one code base. If a single developer breaks the build, then all developers are blocked. The code naturally tends toward deep, multidimensional dependency. Refactoring common code into shared libraries create dependency trees. The amount of rework needed when changing code structure is exponentially proportional to the depth of that structure in the dependency tree. Teams often make the rational choice to wrap complexity in ever more layers, in an attempt to hide and contain it. Monoliths make the cost of parallel work much higher and thus slow development
  2. Monolith gather technical dept rapidly. There’s no natural limiting force. A well-structured, properly decoupled, clean, object oriented initial design is too weak to resist the immediate needs of an entire team working again the clock to deliver today’s features. There are too many ways that one piece of code can invade other pieces of code — too many ways to create dependencies
  3. They are all-or-nothing deployments. you have an old version of a monolith running in production and you have a new version on staging. To upgrade production without impacting the business, you have a very stressful weekend a head of you. the basic problem is that nay change to production requires a full redeployment of the entire code base. this creates high-risk exposure to failures oat all levels of the system. no amount of unit testing, acceptance testing, integration testing, manual testing and trialing can give you a true measure of the probability of failed deployment, because the failures conditions are often direct consequences of production conditions that you can’t simulate. product data only needs on unforeseen aspect to cause critical failures. it is difficult to verify performance using test data — production can be orders of magnitude larger. users can behave in unanticipated ways, especially with new features, that break the system because the team wan’t able to imagine those use cases. The deployment risks associated with monoliths causes slow, infrequency release of new features, hold back fast delivery.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

No responses yet

Write a response