Looking at decades of software development, there is a phenomenon that keeps popping up irrespective of age, technology and computing power. There is a certain break-even point in application growth after which the speed of development starts to fall, complexity rises, feedback cycles get longer and productivity plummets. It turns out that the key driver for this negative trend is “tight component coupling”.
Living in the time of The Great Plague, this relationship is best understood as an exponential curve.
How tight coupling impacts complexity
By moving our architecture toward better modularization and loose coupling, we are managing complexity by applying the “divide and conquer” principle.
It has been a popular belief that just by splitting your complex application into a number of microservices you would solve the complexity problem. While microservice architecture can help in this situation, it’s certainly not the only success factor.
Microservices can help you achieve modularity and loose coupling, but they are not the silver bullet. The trouble is that most organizations are switching to microservices while retaining the old, traditional way of thinking about technical architecture and team organization. Not to mention that microservices are just as prone to fundamental design flaws as monoliths. And that leads to sour experiences and fair warnings posted all over the internet.
Having a poorly structured monolith and expecting that introducing microservices will solve that problem is madness. Instead of one poorly structured unit, you will end up with tens of them and your problems will skyrocket (remember the curve!). There is no shortcut to clean architecture. You need to build it in from the beginning… whether you’re building one monolith or tens of microservices. Microservices do not replace clean architecture, they complement it.
Let’s put monolith vs microservices crusaide aside. There are reasons and use cases for both styles. And both styles are equally susceptible to the following problem.
It’s so easy to start building applications today: there are frameworks that do the heavy-lifting, there is a cloud that enables quick deployment… you can have your Hello World example of a monolith or a couple of microservices running in the cloud in less than an hour. And that is precisely where the problem lies!
Engineers (especially those entering microservice world!) are flooded with such fragmented and oversimplified Hello World examples. It is hard for them to design the new system from scratch and include key development principles and practices simply because they don’t have a useful blueprint describing how such a system should look like. By starting the project relying on knowledge acquired solely by analyzing simplified Hello World examples, they miss the opportunity to build in proven principles and good practices. Sadly, these can later be introduced only through serious reengineering.
Understanding that there is a lack of good reference implementation of fundamental “clean architecture” principles we decided to kick-off an open-source Project Klokwrk to implement a representative blueprint of a complex system based on clean architecture principles. Since these are fundamental design principles, they are applicable to both monolithic and microservice architecture. To raise the stakes, Project Klokwrk will also address microservice concerns. Our wish is to help all those people who are about to start building a new product by providing them with a solid foundation to help them start on the right foot.
To quote Grady Booch, amazing scientist, engineer, philosopher and a dear friend who was our guest at QED conference
Congratulations! You are embarking on a journey that will not only change your life, but it can change the world.
Learn to learn continuously; in the face of the latest fads, remember that the fundamentals of good software development remain fundamental; take care of yourself.
— Grady Booch (@Grady_Booch) May 2, 2020
It has been proven time and again that quality is more important than quantity. It is better to have one solid blueprint that addresses many real-life concerns than many simplified Hello World examples, each addressing only one concern in isolation. Although there are cases when the whole is greater than the sum of its parts, having 100 simplified and isolated Hello World examples is certainly not one of them. Therefore, we strongly feel that Project Klokwrk will be of value to all of us.
We are very excited about this project so stay tuned for more good stuff…
