When financial services and technology meet, they create a unique world with its own set of constraints.
Pierre Paci, Cloud Engineer, takes a look under the hood of the FundsDLT platform and how it has overcome these with some innovative solutions.
The central goal of a company is to solve problems. At FundsDLT, we solve a problem in a unique market: investment fund distribution.
We chose to innovate in this field by applying new technology to the problem, making us a Fintech, or more accurately a Fundtech company. Accordingly, our security and quality standards must be higher than other companies. Many firms will suffer from a data breach and as a result they might end up losing customers. However, in our case, the company’s very existence is immediately at stake.
Fintech requires innovation on firm foundations
That is why we commit to regular security and quality audits of all aspects of our platform. On the other hand, the more innovative the platform, the more complex it becomes. It can become a challenge to keep track of every piece of information in order to give auditors useful and up to date information. Manually deploying infrastructure and extensively documenting every modification requires a tremendous amount of work and time from IT teams.
One tempting path out of this could be to lock the platform to a specific version. Once it is deployed, and after extensive audits, any further change would be denied, thus preserving the state and the integrity of the platform.
However, we are also an innovative company. We cannot afford not to deploy new versions or innovate for a long period of time. Our clients trust us because we are solving problems by bringing new solutions to the table.
So, we have two goals that are competing and it is not feasible to fully commit to only one of them.
Build and automate for reliability and scalability
The FundsDLT view on IT platforms is to deliver innovative solutions that are secure, efficient, and resilient. All at the same time. There are no options for halfway compromise.
“A platform that is not resilient is not acceptable in the financial services industry.”
Pierre Paci, Cloud Engineer, FundsDLT
In the area of security, as mentioned above, every modification done to the infrastructure needs to be traceable, auditable and revertible if needed. We do not wait for an external audit to assess our platform. Automated audit and security tests must be done on a regular basis.
Performance and efficiency are tough problems. At the beginning of every company, it can be compelling to claim having a platform that is high-performance enough to effectively solve client’s issues. But it is not that easy to maintain this claim after onboarding many clients. This is the very well-studied problem of software and infrastructure scaling. Among other things, solving this scaling issue at Amazon resulted in the creation of AWS and, thus, the creation of the entire cloud industry.
For us, a cloud solution is not just a matter of virtual machines. We believe that cloud is mostly about software, principles and methodology. Cloud enables us to scale. The important question is then how and when to know that our software needs to scale (horizontally or vertically)? All our applications export metrics and logs, combined with advanced analytics, that enable us to assess at any moment the performance of the whole platform.
Resiliency is also at the core of FundsDLT. A platform that is not resilient is not acceptable in the financial services industry. Behind the technical terminology of Service Level Agreements, Recovery Time Objectives and Recovery Point Objectives, lies the service quality of the platform. They are so crucial in our market that we must legally commit to offer a reliable service.
Not having a proper backup or high availability strategy is not acceptable for regulatory authorities. But how can we be sure that we’re not making a false promise? Or have the right procedure on paper while hoping that everything will work out when an incident occurs? The question is never if an incident might happen, but when and how we deal with it. This problem is tackled once again by automating tests. This means testing that every component fits together, that every component is regularly backed up, and more importantly that backups can be restored. Those elements ensure that we can respond to any event.
The key is automation and software-defined procedures. The DNA of a fintech company is code. So, it was completely natural that FundsDLT embraced the Infrastructure as Code (IaC) philosophy for its creation and growth.
Overview of our IaC stack
At the core of our Infrastructure as Code stack lies Hashicorp’s Terraform and Kubernetes.
Terraform enables a company to describe multiple aspects of their infrastructure, in a comprehensive and open language. The entirety of our cloud infrastructure and software configuration are declared using Terraform. Combined with a version control system (VCS) such as Git (FundsDLT uses a private instance of GitLab as its VCS system). It allows us to have perfect traceability on our infrastructure since we store who did the modification, when it was done, why it was done, and which components where impacted. This philosophy is called gitops. At any moment, Terraform allows use to check the integrity of the deployed infrastructure compared to what is described in the code.
During external audits, we can have full confidence that what we are describing is in fact what is deployed. To go a bit further, some external auditors have asked for our terraform configuration to be able to assess themselves what was done. This code sharing capability has enabled much faster and smoother cooperation.
“Infrastructure as Code makes automated tests achievable, which means that FundsDLT ensures delivery of a secure, efficient and resilient platform to every one of its clients.”
Pierre Paci, Cloud Engineer, FundsDLT
Kubernetes is a vast project. For the scope of this post, we will describe it as a declarative way to run applications in the cloud. The important word here is declarative. By declaring in which state we want an application to run, and not how to deploy or run it, we can climb the ladder of automation. On top of Kubernetes, FundsDLT uses the Helm project. This project is at the highest level of maturity of the Cloud Native Computing Foundation.
This means that it is today employed by many companies and is considered as having a huge impact on the industry. Our experience confirms this. Using Helm, we can deploy applicative packages. These ready to use packages enable developers to easily ship their code into the platform. In addition to developer’s code, we can add configuration, monitoring probes and dashboard, alerting rules, network security rules, etc. They will all come automatically along the application itself. As Helm is also using the IaC principle, every modification and added or removed components, are traced in our VCS. We have a perfect view on what is run in any environment, and how it is configured. Also, in case of an issue, we can revert to previous versions at any time.
Once the deployment and the application are described as code, it becomes possible to automatically create clones of any environment. This capability itself enables automated tests. Creating a perfect copy of a production environment (except client data), deploying the FundsDLT platform on it and conducting security or performance analysis becomes not only possible, but automatable.
By running automated tests, FundsDLT ensures the delivery of a secure, efficient and resilient platform to every one of its clients.
And that is achievable because of Infrastructure as Code.
