Or, Partial Microservices
There has been much discussion lately around how microservices may not actually be the appropriate architecture for many teams and companies, especially those working on legacy applications. The idea behind this is that while microservices may perhaps be ideal in some circumstances, they most definitely have their limitations, and really are not a good fit for many legacy systems.
When splitting up a legacy monolithic application, it is desirable to work in the direction of microservices. That is kind of the general path you are going to walk down, knowing that it is a long path and you will have many steps to reach the destination. However, there will be many benefits that start to emerge even partway down the path. Here are some of the benefits that start to emerge, even before you’ve reached fully-fledged microservices.
Boundaries
If your team is like most teams, there will only be one person on your team that can somewhat say that he or she “knows the system”. If you are lucky. There might not be anybody on your team that knows the system. Even if you are in the lucky team with experienced knowledge, that one person cannot do everything (hence the need for a team), neither can he even teach everybody else on the team all of the years of knowledge that he contains.
Amongst the undoubtedly priceless knowledge this veteran man or woman contains is likely to be a mental model of which pieces of the system perform which duties. Of course this mental model is not completely accurate, due to numerous hands in the pot and years of change, but it is likely still a better model than anybody else on the team has, and is better than he or she would be able to place on a whiteboard or wiki page.
It may sound strange, but the best way for this knowledge to transfer to the rest of the team is to break the system along these boundaries. Not only will the team get a better understanding of where those boundaries are, but the boundaries themselves will become much harder to drift without some amount of process and fanfare, allowing the team to more easily keep their mental models (and written documentation) up to date.
Start with the big edge pieces, and start peeling your way into the core of the system. Start with the large obvious boundaries, as it will be easy to split out more later if needed, but a horrible time trying to force a boundary where there should not be one.
Independent Deployments And Lowered Risk
As the different modules are split out of the original system, the newly discovered services can become self reliant, and independently deployable. The risk of deploying new code goes down, because the amount of changes included in any one piece is decreased. Changes to critical services can be made faster, and again with less risk. Code that does not change often can just be left alone, and the risk of surprise defects cropping up again goes down.
The individual services shrink down to have more manageable surface areas than the original system did, and now even tests become more manageable and less effort to add, perhaps moving down from brittle UI tests to less brittle API tests. This again helps to increase confidence in changes and lower risk of deployments
Focused Teams
Teams can start to become more specialized and focused now, as they don’t need to maintain proficiency across the entire system, but can start to develop mastery in a certain area; a certain service or set of services that make up the system. Quality and speed start to climb back up because the team is allowed to focus on what they know, rather than constantly learning and re-learning parts of the system.
Macroservices
All of these benefits can be gained at some level before ever hitting what might be considered microservices. Perhaps we can call these still big, but smaller than the original system services macroservices. They still follow many of the principals of microservices, but are not exactly on the same scale.
There will be a point in the refactoring and re-architecture where it will become good enough. The amount of money and effort required to split the system down further will just not be justifiable. The business needs are being met once again with this much cleanup work, and while we undoubtedly would still like to do more, the payoff just isn’t there. As each new service starts to grow, and begin to crack and crumble, the cleanup will be needed again in a few years, but we’ve paid off enough technical debt that we can invest in larger items that will help us out a great deal more than pedantically trying to split a 10 or 20 year old system into a large set of services that will only require a developer an iteration to rewrite.