Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Decommission Your Legacy - What Legacy Can Learn From Microservices

DZone's Guide to

Decommission Your Legacy - What Legacy Can Learn From Microservices

Not everyone necessarily needs microservices, but everyone should know the literature on the subject because that's where you learn to decommission a legacy properly.

· Microservices Zone ·
Free Resource

Learn why microservices are breaking traditional APM tools that were built for monoliths.

At one of my current clients, the question is continually being asked: how do I go about decommissioning our flagship application?

Indeed, my client's IT is extremely focused on it, which is based on a very specific technology, with few knowledgeable people on earth. There is, therefore, a strong desire to decommission it, but also the desire to know how to do it.

This thought made me think a lot about what we can read in microservices literature about the split of the monolith, which led me to reread Sam Newman's book, "Building Microservices."

Split the Legacy

In the case of my client, I see three strong axes:

  • The legacy can only do file transfer, and it requires a migration of the framework to make web services.

  • The legacy contains a lot of tables in the database, but with a pre-existing separation by domain, each domain corresponds to a basic addition of screens, and therefore business functions.

  • The development is very - even too - framed, and does not allow us to develop as we wish. In other words, goodbye dao pattern, refactoring, packaging, etc....

We see directly what can be done:

  • Quickly make this framework migration able to exchange in web service mode,.

  • Cut out the data model by domain, inspired by Domain Driven Design and the job already done, in order to clearly delimit the parts of the model, and then to be able to see how to split. 

  • Replace code domain by domain with another solution. 

Watch out! I'm not talking about replacing it with microservice code. If a cheap editor solution does the job, I would advise my client to take it. At the same time, the IT team is not big, so I don't necessarily think it is appropriate to push for this kind of architecture. The added advantage of this web services capability is that we will be able to lure the model, making sure that the lines of code of a domain pointing on another model will be replaced by API calls.

Step by Step!

After that, we must prioritize. The main drivers are:

  • The wishes of business people. If the business lines want to completely reboot the customer relationship management, this can be a driver to start splitting.

  • The possibility of starting small. It is always good to start with small and non-critical code.

  • Poor coupling. If code spins alone in its corner, catch it, tie it up, and decommission it.

No real surprise, you might say! Yes, but it is with strong convictions that we make things happen. This will remain; by progressively splitting the model, via - among other things - API calls instead of SQL queries, that you will be able to globally decommission your legacy.

Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.

Topics:
microservices ,legacy

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}