In this blog, you’ll learn what legacy code is, some tips to migrate technical debt, how we at Shaadi have migrated one of the aged systems to Serverless Architecture with considerable benefits.
“Reengineering of Legacy Systems should be done for a reason”
With the rapid advancement in technology, new OS, new hardware, new programming languages, libraries get released. And if we do not refactor or change code that frequently it becomes outdated.
Many times projects get finished, developers get moved to new projects and if we have some code that does its jobs well, we stop active development on it and with time it becomes stale and turns into a legacy.
Legacy systems are everywhere and in the process of evolution, every new year brings completely new technologies, hence legacy systems have become a buzzword and everyone in the industry is using it now. Due to this legacy code has taken many definitions. Some of the definitions I found on a well-known forum – stack overflow are as follows.
For me legacy is something that is left unattended for a long time and is still used in business, so now it has high-risk developments associated with it. With time the tech stack has become old and developers’ comfort in working on that system has reduced. And lack of documentation and lack of test cases are adding more worry to it.
There is nothing bad or good about legacy, but according to the statistics, if we modernize our old systems then we have a great chance to get ahead of our competitors.
To determine whether to modernize your application or not, pose a few questions like-
- How hard is it for a developer to make a change in the system?
- Does the system need an extensive test cycle for every small change?
- Is the technology used outdated and do I have a living community around it?
- Is the system scalable, stable and secure?
And if you get a ‘Yes’ then you can think about re-engineering it and replacing it with a new one.You can refactor Monolithic apps to Microservices architecture style, i.e build, deploy, and support the autonomous services in isolation from the other system parts.There is no need to replace a complete Monolithic app but you materially alter specific parts of code. Encapsulate data and functions in independent units and make them available via API calls.
Some of the advantages of Re-engineering:
- Better Maintenance
- Microservice enable us to adapt to new processes very easily. We can choose different technologies for various microservices. One can be written in Java, python, node js based on your needs.
- Microservices have the advantage of dynamic scaling.
- It’s easier to release microservice as components are small as compared to monolithic.
- New features can be shipped to the market fast.
- Cleaner Code – Code blocks to focus on are small in microservices and when you refactor your code you can get rid of patchy workarounds or unwanted code blocks.
- Clearer documentation– While refactoring one can focus on documentation which will lead to easy maintenance and development of the project.
- Integration with 3rd party– Independent microservices are like plug and play and can be easily integrated into any system.
Some ways to Modernize legacy systems:
There’s no one-size-fits-all solution.
- You can Rebuild Selected Components: Rewrite application components functionality by functionality from scratch without changing the application scope. Don’t rewrite the entire application at once.
- You can Re-Platform: Change the runtime environment. For example Containerization of your applications to benefit from Cloud auto-scaling strategies. Don’t make significant changes to any functional code.
- You can Replace: Rewrite the entire application and consider new requirements and needs at the same time
Caution: Replacing the entire application is going to take longer than estimated. A complete rebuild would be extremely risky.
Case Study: Transformation of Cron(time-based) based Profile Screening to Event-driven Serverless Architecture.
What is Profile Screening?
On Shaadi when people create their profile, we ask them to fill out certain basic information about them like name, location and date of birth, caste and religion, College they passed out from, their current employer, food habits, annual income, contact number and a short note describing them and their background.
The form interface where we capture these inputs is made up of dropdowns, free text and radio buttons based on the type of field. In the case of drop downs and radio buttons, the user has to choose from curated list options, but in free text fields, the user is free to enter anything. So, it’s very important to ensure that the user has entered the relevant information, what the field is meant for.On Shaadi, we screen each profile before it goes live on the platform.
Requirement: Rebuild ageing automated Profile Screening to a high-level modern web platform that has better scaling, alerting and observability on system performance.
Solution: Replace existing batch jobs to screen profile input data with an event driven serverless application by adopting a whole new stack ever-changing technology.
OLD SYSTEM
NEW SYSTEM
In a new approach, we have moved away from scheduled jobs to event-based architecture. In Shaadi Application Kafka events are produced when a profile is created in Shaadi to start the screening process. Kafka consumer instance, then pass, then creates a payload with free text inputs of the user and sends it to AWS step-function which orchestrates the complete screening workflow on profile data. If all entered data checks pass then we auto-approve the profile else we send the profile for manual review by CRM advisors.
AWS step-function (orchestration of Screening workflow):
The Micro-services we created in the new architectural design are highly decoupled so it introduces complexities when it comes to knowing where exactly the system is failing. So, good Observability and monitoring is a must. We have used AWS x-ray tracking to give us an end to end view of the request and enables us to look at the state of various microservices which got executed in the flow.
And to zero the manual deployment efforts of newly built microservices we have used AWS SAM.
Some of the benefits which we get from this migration.
- Event based– Screening starts as soon as the user registers rather than waiting for the next scheduled cycle.
- Serverless and Cost effective- We are paying only for CPU and memory used.
- Microservices architecture– Loosely coupled services that can be reused across different projects.
- Smaller Code Base– Just 100-300 lines of code vs. 1,000–3,000 lines of code.
- Faster development cycles.
- Freedom of choice of programming language to perform tasks.
- AWS SAM based deployment
- Robust Tracking and Alerts System.
- Scalable and Reliable.
- AWS step-function maintains the state of execution and allows us to inspect the inputs and outputs of each step.
Hope you have learnt something new and can now confidently take a small step towards removing technical debt.
