If we look back we started creating applications by including every business rule related to a particular business area into a single application. It didn’t matter if functionality had already been written in one application, it would more than likely, be replicated when dealing with another business area.

Legacy Application

This, of course, leads to a maintenance nightmare. There would be multiple developers making different changes to the same application and the same change to business rules having to be replicated across applications.
Overtime as the business has changed and new legislation/regulation has involved changes in the applications the complexity has grown and grown.
In today’s environment matters are even worse – the original developers are long gone – moved on or retired – so there is limited in-house knowledge and the documentation is probably limited and out of date.

Legacy Applications

And this is where microservices comes in to play.
If each business rule had been developed as a stand-alone piece of code (or a microservice) then the maintenance issue goes away along with the challenge of the duplication of functionality.

microservices

This diagram shows the same application constructed as a series of microservices. Each microservice has a clear development team, and each team has a clear, non-overlapping set of responsibilities.

Microservices

The whole point of using a microservices architecture is that it lets you split an application into business rule components that support unique bits of functionality and can be managed by a single team.
So, once the service relating to a business rule has been developed it can be used in multiple solutions and it can be easily maintained and enhanced.

Each development team looks after 1 or more microservices and can carry out their developments without fear of clashing with the work of other development teams.
There are a series of benefits of implementing microservices:

  • Team Management becomes much easier assigning responsibility for particular business rules to a single team.
  • The idea of containerization of functionality becomes more real. The development team needs to understand what happens within the microservice but users only need to know what input is required and what output they will get. The inner workings of the microservice are irrelevant and so long as the interface (input/output) remains the same the underlying technology can be changed or upgraded without impact on the users.
  • Technology decisions can be made at a microservice level so that organizations can make finer decisions about where scarce resources are applied.

The main downside is that by building solutions based on microservices they become more complex in terms of the interconnections between the microservices. These interconnections need managing along with the components themselves and potentially need a development team of their own to manage them.

How to start microservices

The most important component to considering microservices is understanding what current applications do now and decide what they should be in the future. To do this it is necessary to have detailed documentation of the current applications.
Once the documentation has been created then the existing business rules can be optimized to give the microservices that will be needed for applications going forward.
The first steps are to create the documentation and this is a manual headache as the lines of code could be huge and difficult to manually interpret. Automation is an essential tool that is required to make the first steps to a microservice based set of solutions.