Greetings!
I have been working on this big monolithic application for a few years now. Some people called it a Dinosaur due to it is size and the old technical stack.
I have improved my module by applying various modern-day techniques and this is one of those where I restructured all the main REST APIs.
"Let's create a new UI with the latest web technologies" is the other wrong idea. Why do you take so much time (and money) to change a running system? I have witnessed teams taking years to do so but still fail.
"Let's use a new framework" does it solve your business?
A better way to decompose, and improve a monolithic is doing it incrementally while giving business values. We can leverage a beautiful Microservices pattern as well :)
Incrementally migrates legacy systems by gradually replacing specific features with new services. As the features are added, eventually the new service will replace the old system.
However, when we replace features one by one, business is running, and users get new features and new systems as soon as a feature is implemented. Thus, minimizing the migration risk and spreading the development effort over time gives higher business value. If something goes wrong, we can immediately switch back to the old system. Eventually, the legacy system will be "strangled" and no longer necessary and can safely be retired.
https://microservices.io/patterns/refactoring/strangler-application.html
I have been working on this big monolithic application for a few years now. Some people called it a Dinosaur due to it is size and the old technical stack.
I have improved my module by applying various modern-day techniques and this is one of those where I restructured all the main REST APIs.
The problem
When a system gets older without paying attention to technical details, development technologies, tools, hosting, and architecture, everything gets increasingly obsolete. Adding new features becomes very complex. Harder to scale, maintain, and release. In short, it takes months to complete and release a little change.The wrong way
"Let's re-write this" is the normal way people think and that is the wrong way. Why? because it is a running business. It will not add value immediately. There are projects done this way and already years late to production."Let's create a new UI with the latest web technologies" is the other wrong idea. Why do you take so much time (and money) to change a running system? I have witnessed teams taking years to do so but still fail.
"Let's use a new framework" does it solve your business?
The correct way
I admit that there are no correct ways when comes to software development. What we can say is there are better ways.A better way to decompose, and improve a monolithic is doing it incrementally while giving business values. We can leverage a beautiful Microservices pattern as well :)
Meet the Strangler Fig Pattern
Term coined by Martin Fowler by observing how the fig vine strangles trees.Incrementally migrates legacy systems by gradually replacing specific features with new services. As the features are added, eventually the new service will replace the old system.
Benefits
We, developers, would like to chase after the latest-greatest technologies. Complete re-write, and re-structuring a working big system takes a lot of time and cost. Ultimately, we are not delivering valuable content to end users. There are projects that went in this route and have delivered nothing for end users even after years of work.However, when we replace features one by one, business is running, and users get new features and new systems as soon as a feature is implemented. Thus, minimizing the migration risk and spreading the development effort over time gives higher business value. If something goes wrong, we can immediately switch back to the old system. Eventually, the legacy system will be "strangled" and no longer necessary and can safely be retired.
A little bit of UI
This same technique can be applied to migrate the old tech stack in UI (Java Swing) into a more modern tech stack (Angular, React). Instead of moving everything at once, we should add new UIs one by one in smaller increments. In no time, there will be a newer back end and a newer UI.Summary
Use this pattern to gradually improve legacy codebase into well-structured new architecture while still giving business values to end users.References
https://martinfowler.com/bliki/StranglerFigApplication.htmlhttps://microservices.io/patterns/refactoring/strangler-application.html
Comments
Post a Comment