The Microservice trend - Chapter 1 - Cleaner code
This article is part of a series of Article I intend to write on microservices and the few things I have seen. I am not sure how long it will be as I am publishing them as I write them.
In the articles when I talk about an “application” I often mean the end result, microservices will work together for multiple goals, for example to deliver a B2B website as well as B2C website. I consider that the B2B website & the B2C website are 2 applications that relies on the services at the back.
Where do they come from
Still a few years ago we used to develop huge monolithic applications; now the trend is about microservices.What has changed? To understand what is happening let's reverse time to not so far, but to 10 years ago.
We developed and put in place many of these huge applications. These application were tested, and ended up in production and most of them are still running. Maintenance of these applications were passed down from developer to developer. Beside a very few developers all of us have at one point of time worked on the maintenance of one of these “monsters”.
Today (it actually started a few years ago) we realize that these application are becoming more complicated day by day to maintain as they grow more complex and their outdated technological stack becomes even harder to migrate. Onboarding a new developers is not a few days week but sometimes takes weeks, months to complete.
What has gone wrong? In some cases the project started wrong from the start, wrong architectural choices, incomplete specifications; insufficient budgets and so on. Others started good but were ruined, by similar reasons. But there is also abuse of the code. Often we think and people that hires think we can go through an infinite numbers of changes
without any degradations.
Changes to the behaviour of the code is often not possible without either degradation or extensive rewrites of concerned parts. But when a project is on prod extensive rewrites can sometimes be risky and often we don't have time to either do them or test them. So we end up not doing these extensive rewrites. Sometimes it's also simple laziness.
Finally there is incompetence, there is multiple versions of this, either the tools used were not known enought, orthe developers were simply not suited for the task.
End of story, the majority of these monolithic applications transformed to become things that very few understand, and that runs by miracles as the essence of it was lost during the multitude of transformations they have overgone.
Therefore a new idea was born, it's actually an old idea but we will talk about it later. The idea of splitting the big hard to maintain applications into smaller applications each one of them easily maintainable, each of them simple. But the whole still capable of handling the complex needs.
The microservice approach has advantages that in theory should allow applications to be easier to maintain, even if probably more expensive to create at first.
As the individual applications are smaller, they are easier to test, easier to migrate and and easier to remplace. All this means that individually they are cheaper to maintain. For igration for example we can migrate each application individually to the latest version of the PHP or of Java.So we will not need to migrate 100K lines of code once we can do it bit per bit in a more controlled fashion.
I want dwell much on all the benefits and cons as there are other, better articles out there on the subject.
So microservices should in theory solve all our problems right? and allow our application to remain maintainable?
This is where I do not entirely agree with the general consensus.
An old idea simply with better boundaries
Microservices is not a new idea, code decoupling is a principle that existed and was and still used, with reasonable success. But at some point budget, wrong architectural choices, wrong decoupling meant that this decoupling broke. In my experience this happens very often, and quite often not even during maintenance phase but before even going to production.
In case of a monolithic application we will start creating circular dependencies, and create dependencies between parts of the code that shouldn't and very quickly we are going to end up with the spaghetti that we wished to avoid. With microservices, services that were never meant to talk to each other will start to talk to each other breaking the original architectural design and complexifying each individual service. The end result is pretty much the same.
Microservices will make the boundaries of the different components more clear, you can’t simply modify by mistake the code of another service and make it work. It requires more thinking more work. This is good as, but it doesn't solve the main problem; the global architecture.
So is there no solution? There is, but the solution remains the same, whatever we do microservices or not. If the original architecture is questioned due to changes to the specifications a rethink and potential expensive rewrites needs to be done instead of simply rewriting things to make them work. This is true for monolithic applications as well as microservices. Taking shortcuts at anytime of the development process will create technical dept that might very well be in some becomes so massive that it’s more expensive to fix then to start over.
To sum it up, microservices allows a better decoupling of various components; this makes it less likely to for an project to become “messy” but nothing prevents the applications from becoming unmaintainable. As everything microservices is another concept in our bag to use in the right conditions.
In the next chapter(s) I am going to talk more on the number of services required, and on things that needs to be done, and avoided to have a properly applications based on microservices.