Subscribe to our 0800-DEVOPS Newsletter

    Get in touch

    Not sure where to start? Let our experts guide you. Send us your query through this contact form.






      Get in touch

      Contact us for all inquiries regarding services and general information






        Use the form below to apply for course





          Get in touch

          Contact us for all inquiries regarding services and general information






          Blog

          Why Hello World examples are bad for clean architecture?

          12.05.2020

          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!

          As much as they are useful for quick proof of technology, Hello World examples are bad for basing serious projects on them because they are meant to ignore the complexity. They oversimplify the implementation to prove the point and ignore good engineering practices.

          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

          "In the face of latest fads, remember that the fundamentals of good software development remain fundamental"

          Grady Booch

          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…

          Ivan is Director of Engineering at CROZ, 🎙0800-DEVOPS podcast host and O'Reilly author contributing to "97 Things Every Cloud Engineer Should Know". His special areas of interest cover DevOps culture, sociotechnical nature of software delivery and cloud native architectures. Particularly interested in leadership and organizational change, he is helping organizations align business and tech, focus their efforts, and essentially work smarter, not harder. You can follow him on Twitter as @ikrnic.

          CONTACT

          Get in touch

          Contact us