Building software has never been so complex and, at the same time, so simple. The complexity lies in the sheer number of technologies, frameworks, languages and patterns available to us. The simplicity lies in how easy it is to access those technologies and to build software with them.
Because building software is so easy, we often don't worry about the quality of what we are building. Software quality is a key factor in the success of a project. It is what makes software easy to maintain, easy to evolve and easy to fix.
We often focus our study and our time on learning new technologies and frameworks, but forget to study software architecture, and that is a big mistake. Software architecture is what ensures the maintainability, evolution and correctness of software.
Deciding which architecture to use in a project is a very important task and must be done with great care. A poor choice can bring many problems to the project and to the development team, and the big problem is that these side effects may not show up at the beginning of the project, but only over time.
Some of the main problems a poor software architecture can cause are high coupling between modules, low cohesion between modules, difficulty scaling, performance problems and difficulty testing, among others.
Imagine the following scenario: time goes by, and you and your team notice the software is getting more and more complex. It seems that with every new feature, the software becomes more unstable, harder to maintain, harder to evolve and harder to fix. Now what? What do you do?
Then, out of nowhere, the magic word appears: Microservices. Microservices are the solution to every software architecture problem. Microservices are the solution to every problem of coupling, cohesion, scalability, performance and testing.
I agree that microservices are an excellent solution to many software architecture problems, but they are not the solution to all of them.
Have you considered refactoring your code before trying a more complex solution like microservices?
Have you considered studying software architecture before trying a solution based purely on current trends, or on solutions that worked for other companies?
Netflix, Amazon and Google have great solutions to their own software architecture problems, but do those solutions work for your project?
Is it time for you and your team to stop trying magic solutions and start studying software quality and architecture?
Don't you think that using microservices to solve software architecture problems is a form of technical debt?
I won't answer these questions, but I think you should think about them.
I don't think you should never use microservices, but I do think you should think hard before using them.
There are cases where this architecture makes complete sense, but there are many cases where it is only being used to pay off technical debt left by a wrong decision made at the beginning of the project.
Don't despise microservices, but don't use them as the solution to every problem.
Study, learn, and make decisions based on facts, not on trends.
Keeping software at a high quality is hard work that takes a lot of study and dedication, but it is work worth doing.
And you, what do you think? Are microservices technical debt?
Comments