Companies all over the world are in a constant search for technologies that are reliable, enable better data management, mitigate risks, and optimize the workflow for processing daily operations. In this regard, the representatives of the banking and financial sectors need special attention to data, ensuring its usability, connectivity, and efficiency for analysis.
That’s the challenge Intellectsoft accepted to build a tailor-made software solution. For a leading world’s investment fund, we’ve made an Infrastructure as a Code platform with financial analytics tools like blue-green deployment and constant delivery.
While building a solution for financial data analytics, software providers should recognize the uniqueness of each tech task, ensuring the presence of required functionality and security features. In this financial analytics solution challenge, we had to include disaster recovery, information replication, managed service identity, web app firewall, along with other features.
Among other factors, the platform type affects the number of features, and we adopted the appearance of the solution to Microsoft Azure Cloud in this case.
Obviously, this platform is not the only option to deliver the required functionality — Google Cloud also works for disaster recovery, for example — but Microsoft Azure Cloud, as a fully managed cloud, worked better to address the existing business performance challenges, safety requirements, and compliance needs.
This choice was also good for our developers, helping them to accelerate the deployment, hosting, and scaling of the system and its functionalities and APIs.
What’s Inside the App Box?
The financial analytics app we’ve built addresses the need for accessible data analytics that works with information from multiple sources. The solution visualizes the results in an easy-to-use way, meaning generating various graphs, diagrams, tables, and images. Also, the app enables sharing reports with stakeholders as Excel files.
The software takes over numerous tasks analysts struggle with once do them manually. The list includes working with files, filling spreadsheets, unifying the results, and drawing actionable insights. The machine supports all these processes to facilitate the work for specialists.
Even more, the custom app automates the majority of data processing after its development completion. This way, the owner got the opportunity to save time and nerves on managing the project, as employees can see the assigned tasks and distribute the key data in the Excel file format right in the system.
The inclusion of historical records also enabled conducting truly in-depth research, taking into account the variety of users and responsible roles, along with data consistency.
Intellectsoft considers the specifics of existing IT infrastructure while building digital solutions. For this financial data analytics challenge, we conducted all-around research for accurate project scope determination. We chose Microsoft Azure Cloud as the platform that facilitates hosting for upcoming integrations, especially over the long haul.
- Azure App Service (API hosting)
- Azure SQL Databases (data structure)
- Azure Storage (assets storage)
- Azure Storage (static website hosting that works for web apps based on the SPA approach and React.js technology)
- Security services, routing, and other functionalities (more details below).
For the inclusion of the Continuous Integration and Continuous Delivery (CI/CD) concept, Azure Pipelines work the best. Being an integral part DevOps system, these platforms provide the space for numerous exceptional features and utilities, making data analytics in finance usable, efficient, and truly reliable.
For instance, Azure Pipelines support several pipelines and manual approvals, eliminating the great number of human errors. The platforms enable maximum automation for all the processes and operations — wherever possible.
Hosting & Data Storage
Frequently, software systems struggle with network bandwidth and poor app performance. In this regard, the ability to access files in Azure Blob Storage directly, thanks to the presence of the shared access signatures (SAS), creates the basis for reliable file storage. Check out all the technical details in the official documentation — or review our overview of the essence of this approach below:
- The file is a must for client application
- To download this file, the client application needs to send the request to the API
- In its turn, API validates the request, considering permissions and other relevant perspectives
- Once approved, API creates the SAS and sends the direct URL with the SAS back in a file
- The client application uses the URL, enters Azure Blob Storage, and downloads the file
Continuous Integration and Continuous Delivery Concept
The essence of the CI/CD concept is “built once and deployed everywhere,” which means that it’s possible to use various environments to deploy the revisions from every single VCS branch.
The greatest advantage of this approach is the development process acceleration. What’s more, the project becomes more predictable, as each building process generates an immutable artifact that is ready for deployment in development, testing, UAT, and production environments. The artifact contains all the needed information (like built code, dependencies, assets, etc) inside.
Once the artifact passes the deployment process (CD), it experiences changes in its environment-specific configuration settings. With the new configuration values, it enters the cloud right away, without extra verifications of the system.
It’s possible since the unification of environments eliminates the need for top-level checks. Because of this, everything works even if a developer decides to download the artifact on a local PC. Simply put, there is no “works on machine” problem, and the app version will be the same in any environment.
Infrastructure as a Code
Making a financial analytics app requires developing an infrastructure. As the system evolves, its infrastructural elements and configurations change but the codebase remains the same. In this process, missing or wrong configurations are quite common, causing problems for the system’s performance in the live environment.
Infrastructure as a Code (IaC) is the solution to these development and deployment problems. In this infrastructure type, cloud resources get code descriptions and storage place in VCS — as if they are the parts of a system code. When the time for deployment comes, the deployment pipeline conducts the needed changes and creates code for additional cloud resources that appeared during the development stage.
Then, the app is moved to the new resource, following the same scenario for deleted resources or renewed configurations. Everything unnecessary automatically goes to the bin, and everything important will be reconfigured. IaC is stored in the VCS, which means preserving version records and code reviews.
IaC adopts various technologies: Azure CLI, Azure Resource Manager (ARM), Pulumi, Terraform. In this list, Terraform serves the system requirements most accurately, gaining popularity thanks to multi-cloud (and beyond-cloud) support.
The presence of Terraform code both in the VCS and the deployment pipeline lets the developers work without the production infrastructure itself. Even more, the common problems, drawbacks, and troubleshooting processes won’t bother.
Having everything automated doesn’t eliminate the possibility to make a mistake completely. This app code can cause severe problems to the business — especially if they appear in the core system components.
That’s why we supported the release with the Blue-Green approach to deployment. For this, we created two distinct app versions that run simultaneously in two instances (the production itself and the production candidate). This is how the development itself happened under this scenario:
- Production candidate environment gets a new version for deployment
- We checking the production candidate for issues
- Routing traffic (real users) is reverted from the production itself to the production candidate
- Changing the environments for the production itself and the production candidate.
- After shifting the roles, the next deployment stage starts.
In practice, people don’t use “production itself” and “production candidate” terms, but simply call them “blue” (for production one) and “green” (for production candidate). After the new deployment stage, the titles will change: “green” will become the “production one”, and “blue” turns into the “production candidate.”
There is one more reason behind working in two environments, referring to the recovery process and failover from the Azure outages. We’ll describe the details in the next part of this article.