Microservices can help you manage legacy code
Today half of companies choose microservices to build their system. But we tend to forget about the maintenance of code living inside your old application as it’s often not worth migrating. Yes, it hurts the little architect inside you, but…
“Refactor without real value for your clients is a waste of money.”
Most of you have heard that and I personally hate it, because it is often correct. Nevertheless, how can we continue to build new features if they depend on old ones? How can we efficiently solve problems if we always refer to a piece of code that is hard to maintain? And finally, how can we be productive if adding a new field on a web page, takes weeks to be deployed in production? No matter what we try to do, a system will only evolve as fast as its weakest component.
In this blog post, I will try to describe the approach taken by Swissquote and the team I’m working with, in order to solve most of the problems that occur with legacy code. Everything below is the result of engineers improving their everyday lives.
Identify legacy code
Before doing anything your team must agree which piece of code everyone considers legacy. Plenty of tools exist for managing the health of your code base and give you an objective view. At Swissquote we are building mostly Java Applications using integrated tools in the build pipeline for detecting problems.Findbugs, checkstyle, pmd, sonarqube (sonarlint for your favourite IDE) are tools made for this job. Monitoring each application’s rollback rate is also possible.
number of rollback * 100 / number of upgrade
You could also measure the time you spend on basic tasks and the number of tests you have to maintain each time you update the code. Finally, and this is the easiest, try explaining a system’s architecture and boundaries to another developer… If it’s not clear, you just found a good candidate for a microservices upgrade.
Microservices to the rescue
Considering the speed at which our field is moving, a good example of this being the amount of different frameworks node ecosystem has produced, you should consider microservices a real alternative to your current software (e.g. Microservices). It brings strong encapsulation, which allows you to overhaul the code without affecting clients. It’s a matter of time before you switch, not just an option. You need to prepare your infrastructure proactively and be able to accept failure (e.g. Lessons learn from Google and eBay, Uber). Yes, the transition is not only a stack replacement, it also changes your developer’s mindsets and won’t be without pain. Writing monolithic software is way easier than building a service oriented architecture with clear boundaries.
Don’t be afraid, it is worth it!
The first iteration when transitioning to services oriented architecture is simply to wrap all of your libraries to microservices. As a consequence, you will be forced to add boundaries to the different domains of your business in order to have a better overview. The legacy code will be only hidden, but now nothing will prevent you from improving it as long as the API doesn’t change. Testing will be affected but guess what, there are tools to do it (e.g. postman, curl, wget). At the end of the day, it will be far from being perfect, and sometimes you should make compromises, nevertheless the hardest will be achieved.
As a second step, you will find yourself more mature about your application and it will be time to improve its boundaries and focus on the design. Our team had to improve the current state and we designed an architecture that allows us to be more productive with our old libraries. The naive boundaries imposed with the first iteration encouraged us to improve it for the next version. It simplified a lot the maintenance and documentation, allowing us to deprecate parts of the old code.
One of the side effects of continuously improving our system through microservices came from other teams. Indeed, inside a company if you have a high coupling with libraries provided by other teams, you will have to deal with it. Rare are the cases where teams will allocate extra time for you. Nevertheless, as we provide better services, teams start migrating to it. By doing this we push the company forward as a whole, not just ourselves.
Renew with legacy
Every piece of code has its strength and weaknesses. Microservices allow to encapsulate the legacy code and reveal its strengths. Boundaries therefore help improving this legacy code while avoiding negative effects. This great power comes with responsibility, and you will be challenged on new complex problems that will require your expertise.
Images: https://pixabay.com
