Navigating the Transition: RS-Bank's Shift to a Domestic Tech Stack
July 30, 2024, 11:32 am
In the world of banking technology, change is a constant. The recent shift of RS-Bank to a domestic tech stack is a testament to this. This transition, initiated in December 2022, aims to replace foreign technologies with homegrown alternatives. The project is not just a technical upgrade; it’s a strategic pivot in response to geopolitical pressures and the need for self-sufficiency.
The automated banking system (ABS) at the heart of this transformation is a complex entity. It serves various functions, from customer service to securities management. This system was originally built on a foundation of foreign technologies, including Microsoft Windows and Oracle databases. The challenge was to replace these components without disrupting the bank's operations.
The first step was to select a new operating system. Astra Linux emerged as the front-runner. This choice was driven by its compatibility with Russian software requirements. The bank's server and terminal components had to adapt to this new environment. The transition was not merely a switch of operating systems; it required a complete overhaul of how the ABS interacted with its underlying infrastructure.
The database management system (DBMS) was another critical area of focus. The original system relied heavily on Oracle. The decision to adopt PostgreSQL Pro was significant. PostgreSQL is an open-source alternative that aligns with the goals of import substitution. However, this transition was not without its hurdles. The ABS had been designed to work with Oracle's ODBC drivers, necessitating a careful adaptation to PostgreSQL's API.
The project unfolded in three main phases. The first phase involved adapting the system to run on Linux. This was no small feat. The ABS is a monolithic application, and breaking it down for Linux compatibility proved challenging. The team opted to use Wine, a compatibility layer that allows Windows applications to run on Linux. While this approach allowed for some continuity, it introduced its own set of complications. Certain Windows API functions were not fully supported in Wine, requiring the team to rework how processes were launched.
Memory management also became a concern. Applications running under Wine consumed more memory than their Windows counterparts. This discrepancy stemmed from how Wine handles dynamic link libraries (DLLs). In Windows, system DLLs are shared, while Wine treats them as private, leading to increased memory usage. Despite these challenges, the majority of the ABS codebase functioned well under Wine.
The second phase focused on report generation and printing. The previous system relied on ActiveX components within Microsoft Office for document creation. Transitioning to Apache POI allowed the team to generate reports without relying on Microsoft products. This shift not only streamlined the process but also ensured compatibility with Linux-based office suites. The reports could now be opened with any office software that supports OOXML formats, further enhancing flexibility.
The final phase tackled the adaptation of the ABS to PostgreSQL. This was the most labor-intensive part of the project. The existing SQL queries were written in a format specific to Oracle, which posed a significant challenge. The team developed a converter to translate Oracle SQL into PostgreSQL-compatible queries on the fly. This converter had to handle a variety of SQL constructs, many of which were discovered only during the adaptation process.
The complexity of stored procedures added another layer of difficulty. The decision was made to retain the PL/SQL format for stored code, but a converter was created to transform it into PL/pgSQL for PostgreSQL. This approach allowed the existing code to remain largely unchanged while ensuring compatibility with the new database system. However, the differences between PL/SQL and PL/pgSQL were substantial, particularly regarding the handling of collections and other data structures.
As the project progressed, it became clear that not all SQL queries could be easily converted. Some required significant rewrites, while others were simply too complex for the converter to handle effectively. Ultimately, about 20% of the SQL queries needed modification, while the converter successfully processed the remaining 80%.
The transition to a domestic tech stack is not just a technical upgrade; it represents a broader strategy for resilience and independence. The project is ongoing, with load testing and pilot implementations currently underway. The results of these tests will determine the next steps in the rollout of the new system.
In conclusion, RS-Bank's journey to replace its foreign technology stack with domestic alternatives is a multifaceted endeavor. It highlights the challenges and complexities of such a transition while underscoring the importance of adaptability in the face of change. As the banking sector continues to evolve, the lessons learned from this project will undoubtedly inform future initiatives in the realm of technology and finance. The road ahead may be fraught with challenges, but the commitment to self-sufficiency and innovation will pave the way for a more resilient banking infrastructure.
The automated banking system (ABS) at the heart of this transformation is a complex entity. It serves various functions, from customer service to securities management. This system was originally built on a foundation of foreign technologies, including Microsoft Windows and Oracle databases. The challenge was to replace these components without disrupting the bank's operations.
The first step was to select a new operating system. Astra Linux emerged as the front-runner. This choice was driven by its compatibility with Russian software requirements. The bank's server and terminal components had to adapt to this new environment. The transition was not merely a switch of operating systems; it required a complete overhaul of how the ABS interacted with its underlying infrastructure.
The database management system (DBMS) was another critical area of focus. The original system relied heavily on Oracle. The decision to adopt PostgreSQL Pro was significant. PostgreSQL is an open-source alternative that aligns with the goals of import substitution. However, this transition was not without its hurdles. The ABS had been designed to work with Oracle's ODBC drivers, necessitating a careful adaptation to PostgreSQL's API.
The project unfolded in three main phases. The first phase involved adapting the system to run on Linux. This was no small feat. The ABS is a monolithic application, and breaking it down for Linux compatibility proved challenging. The team opted to use Wine, a compatibility layer that allows Windows applications to run on Linux. While this approach allowed for some continuity, it introduced its own set of complications. Certain Windows API functions were not fully supported in Wine, requiring the team to rework how processes were launched.
Memory management also became a concern. Applications running under Wine consumed more memory than their Windows counterparts. This discrepancy stemmed from how Wine handles dynamic link libraries (DLLs). In Windows, system DLLs are shared, while Wine treats them as private, leading to increased memory usage. Despite these challenges, the majority of the ABS codebase functioned well under Wine.
The second phase focused on report generation and printing. The previous system relied on ActiveX components within Microsoft Office for document creation. Transitioning to Apache POI allowed the team to generate reports without relying on Microsoft products. This shift not only streamlined the process but also ensured compatibility with Linux-based office suites. The reports could now be opened with any office software that supports OOXML formats, further enhancing flexibility.
The final phase tackled the adaptation of the ABS to PostgreSQL. This was the most labor-intensive part of the project. The existing SQL queries were written in a format specific to Oracle, which posed a significant challenge. The team developed a converter to translate Oracle SQL into PostgreSQL-compatible queries on the fly. This converter had to handle a variety of SQL constructs, many of which were discovered only during the adaptation process.
The complexity of stored procedures added another layer of difficulty. The decision was made to retain the PL/SQL format for stored code, but a converter was created to transform it into PL/pgSQL for PostgreSQL. This approach allowed the existing code to remain largely unchanged while ensuring compatibility with the new database system. However, the differences between PL/SQL and PL/pgSQL were substantial, particularly regarding the handling of collections and other data structures.
As the project progressed, it became clear that not all SQL queries could be easily converted. Some required significant rewrites, while others were simply too complex for the converter to handle effectively. Ultimately, about 20% of the SQL queries needed modification, while the converter successfully processed the remaining 80%.
The transition to a domestic tech stack is not just a technical upgrade; it represents a broader strategy for resilience and independence. The project is ongoing, with load testing and pilot implementations currently underway. The results of these tests will determine the next steps in the rollout of the new system.
In conclusion, RS-Bank's journey to replace its foreign technology stack with domestic alternatives is a multifaceted endeavor. It highlights the challenges and complexities of such a transition while underscoring the importance of adaptability in the face of change. As the banking sector continues to evolve, the lessons learned from this project will undoubtedly inform future initiatives in the realm of technology and finance. The road ahead may be fraught with challenges, but the commitment to self-sufficiency and innovation will pave the way for a more resilient banking infrastructure.