Software Architecture Unveiled: A Series by Igor Fraga
Hi everyone, Igor Fraga here. This is the fourth article of these series to unveil the challenges and the role of what we do as a Software Architect.
As an architect, one of my most important jobs is to choose technology. It is also one of the most dangerous jobs.
We always see new, exciting tools that promise to be fast and wonderful. I call these tools the Beauty.
But we also have old, reliable tools that we know will work. They may not be exciting, but they are strong. I call these the Beast.
It is a big mistake to choose the Beauty and forget the Beast. I know this because I've seen this mistake happened multiple times, also on a project with a very good team. Here is what happened.
The Story: The Dream of a Super-Fast System
Some years ago, a company called X (I'll not reveal the name here, of course) needed a new system to handle many events from thousands of users worldwide, integrating their platforms that until then, were separated.
The goal was to process these events very quickly, with very little delay. Our team was smart and experienced, but the architect thought a reactive Java system was the best way to do this.
The Beauty he wanted us to use was a technology called Project Reactor and Spring WebFlux. It promised amazing things:
It was non-blocking. This means it could handle many tasks at the same time without waiting. It would be much faster than old systems.
It used fewer resources. It could manage thousands of connections with only a few threads. The old way needed one thread for each connection.
The code was clean. It was a modern and simple way to write complex code.
The other choice was the Beast we knew very well: the classic Spring MVC. We used it for many of our other systems. It was strong and our whole team understood it.
The team was kind of skeptical about using reactive but the architect insisted on saying it was the only way to be fast enough.
I was worried it would be hard to learn and maintain but over all, if this paradigm were really necessary within a virtually all legacy arrangement.
But we had no choice, and he didn't listened to anyone, he just came out with a skeleton of the service so we should work above that.
So, let's build the modern, super-fast system.
The Problems Begin: When the Dream Becomes Hard
We built a small test system, and it was very fast. We were happy and thought we made the right choice.
Despite the learning curve and the complete coding paradigm shift, we've managed to make it out somehow.
But then, we started building the real system for production. That is when the problems started.
Debugging was a nightmare. The code was made of VERY long chains of operators. When there was an error, the error message was very hard to understand. It was difficult to see where the problem happened.
Other tools did not work well with it. We used many other tools for things like security and data. We found that these tools were not reactive. They were blocking. When we used them, they broke our new system’s non-blocking design.
There were new kinds of bugs. We had problems that were very hard to find. For example, the system would slowly use more and more memory, and then crash. We did not know why.
Our team stopped building new features. Instead, they spent all their time trying to fix these new, hard problems.
The beautiful, super-fast non-blocking code we wanted was now full of complex fixes and we were losing our hairs on it.
I'm not saying that the reactive programming is bad and should be avoided or that it doesn't works. What I'm saying that, for this case, it never made sense at all. It was a real nightmare without any real business benefit for this particular project.
The Solution: A Checklist to Help Us Choose Better
This bad experience taught me an important lesson.
Now, when I'm choosing tech stack, I use a simple framework to help me choose new technology.
It is not to stop new ideas.
It is to make sure we choose new ideas in a smart way that makes sense to each purpose.
Technology Checklist
1. Is it Ready and Stable?
Version: Is it a stable version (like 1.0 or higher)? Early versions can change suddenly. Take for instance, the disruptive changes from Spring AI M5 (milestone release) to final 1.0.0 GA public release.
Team Skills: Does our team already know how to use this? Or is it completely new for everyone? Consider specially the schedule and available time when looking at this.
Community: Is there a big community of users? A good community helps fix bugs and answer questions.
2. Does it Work with Our Other Tools?
Compatibility: Do our other important tools work well with this new technology?
Integration: Is it easy to connect with our systems for monitoring, security, and deployment?
3. Is it Easy to Learn?
Good Documentation: Is there clear documentation with good examples? Does it explain common problems?
Learning Time: How long will it take for our team to learn it well?
4. Is it the Right Choice for Our Project?
Good Fit: Is this technology a good solution for our specific problem? Or do we just think it is cool?
Small Test: Can we build a small test project first? This test should check the riskiest parts.
Backup Plan: If it does not work, is it easy to change to a different technology?
How you can decide
Today, when thinking about a new technology, follow three simple steps:
Use the Checklist: The team fills out the checklist together.
Build a Small Test: Building a small test project to check the most dangerous parts.
Write Down the Decision: Write down why the team chose it (both architect and developers, TOGETHER), what the risks are, and how they will be managed.
Final Thought
Choosing technology is about managing risk.
The Beauty of new tools is exciting, but they can be immature and risky.
The Beast of old tools is predictable and safe.
A good architect understands both.
They know the most important thing is that a system works well and the team can maintain it.
In the next article, we will talk about how to design systems that can change easily, like building with Lego blocks.
See you then!
Top comments (0)