What Lies Beyond a Microservice Architecture? — Software is Alive!
In recent years, Microservices have gained popularity in technology architectures due to their potential benefits, such as scalability, flexibility, and the ability to break down complex applications into smaller, more manageable services. However, as all software developers know, every choice may have its downsides, and it’s no different with Microservice Architecture. Similar to Monolithic Architecture, over time, it can become challenging to maintain, and certain ‘bad smells’ may start to emerge. Does this also happen with Microservice Architecture? If so, what lies beyond it?
This is the first article in a series of 3 which you will learn some strategies to take a step forward from Microservice Architecture. These strategies can help you create a more sustainable and healthy architecture. In this article, you will learn why software should be seen much more as a living organism than a tool.
Bad Smells
First, let’s recap the concept of “Bad Smell”, conceptualized by Kent Beck and Martin Fowler, both well-known figures in the software development community, popularized in the book “Refactoring: Improving the Design Of Existing Code”.
This concept, or, let’s call them “code smells” enhances that a code has characteristics that make it harder to maintain, understand, or extend. Just as a bad smell in the real world indicates that something might be wrong or decaying, in code, it indicates the same feeling.
The book introduces the idea of identifying and addressing code smells as part of the refactoring process to improve its readability, maintainability, and extensibility.
One interesting point to ponder is that we often start a new software with the best practices: TDD, Design Patterns, and Clean Code… but somehow it starts to degrade. Have you ever thought about why it happens? You might have thought of some reasons, but the fact is that Software is Alive!
Software is Alive!
That’s right, software is alive! It’s constantly evolving, adapting, and responding to changing requirements and conditions, almost like a living organism, wouldn't you agree?
This concept has gained popularity in the context of Agile and DevOps methodologies, which emphasize the best practices of continuous integration (CI), continuous delivery (CD), and ongoing maintenance and improvement of the systems.
Software should be able to grow, change, and respond to its environment. It should be flexible, resilient, and able to evolve over time. Doesn't it align with the principles of agile development? Indeed, it involves responding to change and delivering functional software quickly and regularly.
That’s why I like to think that software should be seen more like a Baby than a tool. A tool, such as a bicycle, a car, or even a pint of beer, doesn't change its behavior over time, it has a static functionality — once built, it never changes. But a Baby… it’s always evolving, often faster than we can imagine.
A Baby is always evolving! Often faster than we can imagine.
So, what would be the relation of a baby with software? Let’s take a look at how babies might improve their skills over time!
Baby Skills/Software Features
Software is constantly changing, evolving, and adapting, and new features are created so quickly that it can be deployable every day! A Baby is quite similar; when born, they have only a few skills: crying, breathing, sleeping, and tending to their needs.
For those who have had the chance to have a kid, you may have noticed how quickly they grow and learn new skills! Within a month, they begin to see and pay attention to their surroundings. Between 10~14 months, they start walking. After a few years, they learn to ride a bike, and as adults, they might have their own kid, and the process repeats.
When considering the graph of skills learned throughout their lifetime, what do you imagine it might look like?
As a software developer, every time I see an exponential graph, it brings back memories of my university days, especially the Algorithms classes, which were among the most challenging. When examining this graph, it becomes evident that a new analogy between a Baby and Software emerges: they can be represented with a Big-O Complexity chart.
While in software development, we typically avoid creating algorithms in the “red zone” of Operations X Time, when considering a baby’s development, this analogy can provide a helpful perspective when examining Skills X LifeTime. Software, though, is not only about code, an Architecture might exist behind it!
Is it possible to use the Big-O Complexity Chart to understand and analyze an architecture?
So, how we can use the Big-O Complexity Chart to analyze architecture? In the next article, we will explore how this concept can help you measure architectural complexity and take a step forward to a new architectural change.
