What is your strategy for migrating applications in your organization?
In several clients that we are serving, there are scenarios where we are faced with numerous legacy components in organizations. Many of these are crucial and fundamental for the operation of the business, however, there are the challenges of modernizing them in the most adherent way to the demands of all industries in the market.
Application Strangling Pattern
The Throttle Pattern has become very popular, having been documented on the microservices.io website ( https://microservices.io/patterns/refactoring/strangler- application.html), the objective of this pattern is to make legacy applications change gradually, changing services in a way that consumers and channels are impacted as little as possible.
Stage 1 | Consumer channels access 100% of the Legacy Service |
Stage 2 | We created a Facade, which is also a strategy inspired by the Pattern Façade (GOF) - https://en.wikipedia.org/wiki/Facade_pattern, but in this case, we can create a specialization of this patter which is the Facade API (Facade API - https://cloud.google.com/ static/files/apigee/apigee-api-facade-pattern-ebook.pdf ). The objective of this façade is to abstract the communication between the channels and the service ends, in this case, access may be 80% in legacy components, and 20% in already modernized components. |
Stage 3 | As the legacy system functionalities are modernized into smaller services, that is, breaking this monolith into smaller services (micro or macro services), let's say that at this stage the consumer channels via the API Façade, can now access much more of the functionalities of the modernized services and no longer all the capabilities of the legacy services. |
Internship N | At some point, the result of this strategy is to simply turn offthe legacies. |
Types of Legacy Components most found by our Consulting team
Stored Procedures and Database Components
More than 20 years ago, it was very common to build applications in the client-server model (Client-Server), which could be divided into two forms: Thin Client/Fat Server and Fat Client/Thin Server. Due to the much greater computational capacity on the server side, the Fat Server model was much more used, which resulted in the creation of Desktop applications using Delphi, Visual Basic, Fox pro, Oracle Forms, accessing databases as numerous functions (Stored Procedures) , due to the great power of databases at the time, for example, Oracle, which has PL/SQL, which has an incredible capacity to not only concentrate business rules but several functions that facilitated the construction of extremely robust applications. Let's use here an example of an architecture made for a client with a combination of Delphi and Oracle:
Many customers have numerous business rules, even integrations built with PL/SQL. With the issue of Windows support, many of these applications for example Delphi, but even other technologies from the 90s/2000s may have problems to keep running, for that reason, some of these companies are literally desperate and the reason is "How can I migrate this solution to another system, considering that all my rules cannot be ported?
What was our proposal?
Acquiring a new ERP would be complex, as there would still be the problem of migrating business rules. So what do we suggest?
1- A new front-end single page application with Angular, porting the desktop user experience, adding all the modern day improvements.
2- This new SPA application would access REST APIs, which act as facades to access all the functionalities and rules that are still in the Oracle Database.
3 - The focus was on critical functionalities, and with that, new users started using this new frontend, which interacted with the same data as the legacy Delphi application.
4- Gradually, all features were ported to the SPA, making them 100% compatible with the features of the Delphi desktop application.
5- With the users migrated to this new UI in the SPA application, the desktop application is no longer used.
6- With the use of APIs, any and all functionality written in PL/SQL could give rise to a new microservice using technologies such as docker, kubernetes, protocols such as WebSockets, etc.
7- The new architecture, in addition to microservices, now has 3 databases, some things still in Oracle, but also coexisting with MongoDB and Redis.
Benefits for the Customer and the Business
Savings: The customer did not need to invest in a new ERP, which would be a significant investment.
Migration and Customization Risk Reduction: Customizing an ERP bringing existing rules is one of the riskiest and also most expensive tasks for modernizations in this sense.
Improvement of Experience: Users have preserved the functionality of the Desktop, with the richness of a Single Page Application, with all the improvements applied by the disciplines of UX (User Experience).
Service for new business channels: For access by third parties or partners, they can integrate through APIs that now act as a central input layer for all services.
Conclusion
This is an example of the work we do for several clients, paying attention to the particularity of each one of them, applying a methodology we call RNC(https://www.skalena.com/modernizacao-legados-skalena), soon we will publish Part II of this article, where we'll talk about strategies for modernizing WebServices/SOAP and in Part III, about the concept of Lift & Shift.
Do you want to chat, have a coffee or even a 30-minute conversation session about these and other subjects? Send us a message: