Optimizing ING's Service Performance with Microservices
ING Bank Śląski
A microservices-based redesign boosted website scalability and efficiency
An online financing service was experiencing much more traffic than expected, which negatively impacted its efficiency. To meet this challenge, we rebuilt it to utilize microservices, allowing it to meet heavier demand while increasing the architecture’s scalability and flexibility.
Our long-term cooperation with ING Bank Śląski has included numerous IT projects. For several years, we have been working on ALEO.com, Poland’s largest online business directory. Its users can access business’ registration data, public financial documents, verified opinions, and customer ratings. In addition, there are purchase and sales tools that can help users improve their company processes.
Performance optimization through microservices
Supplier Financing is an innovative service created with ING Bank Śląski.
Performance optimization through microservices
The service allows to finance invoices quickly and easily before the due date.
ING’s Supplier Financing
In 2014, as part of the ALEO.com project, we worked with ING Bank to create the Supplier Financing for the Polish market. This service relied on the model of reverse factoring: companies can easily and promptly finance selected invoices before their due date, allowing the supplier to immediately receive payment on order delivery. Buyers can also elect to pay their invoice at a later date.
"On the ALEO.com platform, Supplier Financing was the first banking facility available – other than online banking. While designing the application, we focused mainly on providing users with operational functionality in the shortest possible time. We also wanted to offer flexible financing options that matched the needs of both buyers and sellers".
At that time, our common goal was to cut the launch time for Supplier Financing to the bare minimum. We prioritized a fast launch and market needs over application scalability. However, the application sustained much higher traffic and processed a much larger volume of invoices than we had originally planned.
Business growth spurs tech needs
Between 2014 and 2017, the number of invoices processed by the system grew by an order of magnitude – and continued to soar. The service grew rapidly, but the skyrocketing number of clients had a downside: the application’s performance gradually declined. We regularly monitored system conditions, but the system architecture at that time allowed for limited vertical scaling only. Yet, the business need was for efficient and cost-effective scaling that could support an even higher number of users. ING hoped to simultaneously expand the system’s functions and increase the capability of the architecture, thus helping the bank to win more customers.
In short, we needed to adjust the technological solution to a new business reality – the success of ALEO.com and Supplier Financing.
Decomposing a monolithic architecture
A key obstacle to the platform’s further technological development was its monolithic architecture, where business domains were split at the level of internal components of one big application. Therefore, we decided to separate the Supplier Financing and follow the concept of microservice architecture – extracting the service’s domain and business processes to dedicated systems (microservices). Changes were made to the entire system, including its core. We also needed to create a new data model.
Two goals drove us forward:
to support a growing number of clients and financial transactions.
to eliminate performance hurdles.
"We decided to migrate to microservices, which provided more efficiency, flexibility, and scalability. It also streamlined solution implementation processes in the production environment. This was of utmost significance, given the scale achieved by ALEO.com and Supplier Financing".
"As Supplier Financing was growing steadily in business areas, we shifted to a microservice architecture in baby steps, parallel to developing functionalities" - adds Anna Sobotnik.
Why choose microservices?
Around the world, technological giants are rebuilding their applications as microservice ecosystems instead of monoliths. This solution has been adopted by Netflix, Amazon, Uber, eBay, Spotify, and many others. The reason is simple: microservices offer more agility when implementing change and responding to business needs.
Flexibility
In a microservice architecture, new functions are implemented by modifying an existing microservice. Software development often boils down to introducing one microservice, without the need to disrupt the entire application. Compared to changing a monolith, the process is simpler and faster: there’s no need to check the functioning of the whole application, just the modified microservice. It also mitigates the risk of regression errors, as the automatic verification tests which check the accuracy of a given function were written before that function was designed.
Scaling
After migrating to microservices, ING Bank can more flexibly scale their service. Whenever Supplier Financing faces a heavier-than-usual workload, simply re-scaling the microservices related to this service (rather than the entire ALEO.com infrastructure) is sufficient to handle the increase. This also means a serious reduction in network infrastructure expenditure, which translates into savings for ING’s customers.
During the system architecture decomposition process, we always kept the end user’s perspective in mind. Thus, we simultaneously added new functions to the Supplier Financing. We tried to avoid letting the architecture redesign stifle the regular response to current business needs. To accommodate this, we chose an evolution path: expanding the system with new functions at the same time as we changed the infrastructure. An Agile approach was helpful here.
Project methodologies
Test-Driven Development
We used the Test-Driven Development (TDD) method in this project. This method assumes that the right application code is created only when tests to verify the accuracy of the code have been designed; it mitigates the risk of regression errors and supports high coverage of the code with unit tests, resulting in a much lower number of application errors.
"Thanks to using the Test-Driven Development approach, we have observed a lower number of regression errors; this means we can commit more time to developing the system based on the experience of our users".
In TDD, the entire application development process is faster and more flexible. Its methodology ensures programmers operate in a secure environment that can implement complex changes – something that’s extremely important for financial systems. It’s not necessary to regularly and manually verify whether the recently added application codes work; in TDD, tests are run automatically. This saves time spent defining and reporting a manually identified error.
Scrum
The entire project was carried out using Scrum methodology, which is part of the Agile movement. This allowed the Product Owner to constantly stay informed about the state of work. Plus, the team could promptly respond to new needs as they arose.
"Using Agile project management methodologies to develop software not only creates an agile IT infrastructure, but it also contributes to building an agile corporate culture. It translates into the Agile philosophy of complex change, which can be implemented in an efficient and controlled way".
We strove to find and eliminate problems, prevent future issues, and work out innovative solutions. We were driven by the imperative of continuous improvement performed in baby steps. During retrospect meetings, the whole team worked together and searched for ways to refine the areas discussed in the session.
We also employed some elements of the Lean approach, such as Kaizen and the 5 Why (5W) method. The latter is used in the Toyota Production System to get to the root cause of a problem by asking "Why?" five times after a problem has been spotted. The following example illustrates its use:
In a Toyota factory, an employee is throwing sawdust on the floor.
Questions
|
|
| 1. Why are you throwing sawdust on the floor? | Because the floor is slippery and can be dangerous. |
| 2. Why is the floor slippery and dangerous? | Because it is covered with oil. |
| 3. Why is it covered with oil? | Because there is a leak in the machine. |
| 4. Why is there a leak in the machine? | Because oil goes down the connector. |
| 5. Why is oil going down the connector? | Because the connector's cover is worn out. |
The method allows us to break problems down into individual blocks.
Results and further plans
With the newly flexible and efficient design in place, ING Bank Śląski can now increase their focus on winning new clients and scaling their business without worrying about the technical foundation of their system. Three key changes have been observed:
|
a reduced number of service requests.
|
|
an accelerated change implementation process. |
|
reduced risk of regression errors. |
The results of this have been so good that we’re jointly planning to decompose the entire ALEO.com system into microservices. We’re also looking at redesigning the front-end and UX design of the Supplier Financing.
We can also help your company. Write to us and we will analyze your business needs and determine how to improve the employee and customer experience.