In the previous section, we’ve revealed what’s inside the financial data analytics app, its main technical challenges, and the solutions of CI/CD concept, Infrastructure as a Code, and blue-green deployment. Here, we’ll describe the disaster recovery and security features for financial analytics solutions.
Cloud Provider Infrastructure
Cloud providers like Microsoft Azure have these features inside:
Availability Zone (AZ) — the physical location of the data center and its physical location. The high level of accessibility comes as the result of deployment in different availability zones. The distance between availability zones should be 100 km max.
Region — the clusters of neighboring data centers with high-speed connectivity. Again, high availability comes as the result of this feature. The distance between regions should be 300 km min.
Because of regions’ peculiarities, the chance of simultaneous outages is minimal. They also have unique identifiers. For example, it can be westeurope (signalizing the West of Europe location) or eastus2 (which means it’s in the east of the U.S.). In terms of the blue-green deployment, “blue” and “green” examples have different region identifiers, which ensures their isolation from each other.
For more details on the features of cloud providers, please read the official documentation.
Azure Front Door
Traffic routing is the key stage of the failover process and blue-green deployment. Frequently, the developers use an option to adjust DNS records for the new users’ needs. But the risk of having a broken instance after the record adjustment remains unsolved in this scenario, increasing the downtime anyway.
Numerous cloud offerings can solve this problem, introducing the abstraction concept between front-facing URLs and backend services. With them, client apps will address the front-facing URLs in any traffic routing scenario. Microsoft Azure is such a solution. For more information, read its official documentation.
Why we chose Azure Front Door (FD) for the solution:
HTTPS traffic and application-level routing for traffic come right to the API and the asset storage.
It deals with failover scenarios
It serves the needs of a global service perfectly.
Here are the FD rules:
“Blue” and “green” instances are accessed directly
The system is accessed generically, pointing to “blue” or “green” instances after deployment. This configuration can be changed, enabling routing to the problematic instance in case of disaster recovery.
Here are the ways to route the users during deployment or disaster recovery.
Changing applications and their data require different approaches during deployments and failovers. An app upgrade usually happens by replacing old files with new ones within its set.
But changing data requires a more sophisticated approach, as it’s generated by users on top of the existing application. In case of introducing a new file format to the app, you’ll need to conduct data migration during the deployment.
When it comes to failovers, you need to ensure reliable storage for the existing data. In case of traffic redirection to another app in a different region, you need such storage in both regions at once so that the data serving remains stable in a new region and the system remains up and running after the first region becomes totally down.
The data types used in the system:
structured data (Azure SQL Database)
assets (Azure Blob Storage).
To reside data in two regions in parallel, we recommend adopting the replication approach, where changes in the primary location get an automatic reflection in the new one. To get more information on databases, read the official documentation. Also, it’s useful to check out the guide on Azure Blob Storage here.
Primary and secondary instances of Azure Blob Storage and Azure SQL Database
System’s connection strings to the database and assets storage to include the information to the new primary instances
The Azure Front Door rule for another instance.
During outrages, the Powershell script is the tool that enables the sequence of these actions. If the system’s lifetime is around a year, no records on outrage occurrences are available. That’s why having a working and well-tested failover procedure is the key mission-critical element for the system.
Azure Active Directory
Modern systems frequently face user credentials storage problems, and their third-party solutions are sophisticated and costly (like introducing passwordless login, multi-factor authentication, etc). However, they introduce the Single-Sign-On scenario, which works well for a one-entry user experience of logging in once and getting access to the entire systems set.
Azure Active Directory is such a set of systems that can be leveraged by a sole Azure Portal. Besides, it doesn’t keep any user’s credentials, as admin access manages this information too.
Secret is the apps’ compilation of sensitive information for getting access to external API, database, or any other credentials-storing service. Using Vaults helps here: the system with Microsoft Azure hosting can adopt Azure Key Vault service for satisfactory data security.
In the beginning, the system doesn’t store sensitive information in the repository but simply reads it from the Key Vault. Only selected people have permission to read and write secrets after proving to the client the need to request some keys from the third-party services. For more details on how Azure Key Vault works, read its official documentation.
Managed Service Identity
After Key Vault setup, the system can access its secrets. In case several users get permission to get the API key from the repository, they will have the same access levels to Secrets Management by default. For identity “personalization,” Microsoft Azure has an option to create the Managed Service Identity. Read more about this feature in the official documentation.
As for the next steps, you can assign the Azure App Service identity so that the system gets full access to the secrets, with no need for storing extra credentials in the code repository anymore.
Web Application Firewall
The remaining security element to review is Azure WAF. Same as for the previous elements, adopting ready-made systems is the best practice in this case. The greatest advantage is stable defense in front of the most frequent cyber-attacks — and with the real value-for-money.
In technical terms, a pre-configured WAF instance analyzes the system traffic that comes through the Azure Front Door. It checks and automatically blocks suspicious requests, without the need for extra coding. The service possesses a set of rules that follow the security standards (like OWASP Top 10 vulnerabilities), upon which you can build your own custom rules for certain patterns.
A blocked request comes as the result of WAF-verification failure. In this case, a user sees a 403 error, which prevents the system overload and minimizes the possible damage in the case of an emergency. For more information about Azure WAF, check out the official documentation.
With all the above-mentioned technical enhancements, the company gets the working tools to quickly react to the market changes and remain stable.
New entries and data processing operations we’ve described significantly facilitate data management and analysis, providing you with the needed level of control over your IT infrastructure. The data inputs come quickly, the updates happen automatically, and notifications to all the stakeholders are sent instantly.
In a long run, this investment enables establishing a proactive approach to serving clients and improving the quality of your data-driven decisions. And all this comes for fewer man-hours and with the real enhancements in the bottom line!
The post How to Create Custom Software for Financial Analytics: Intellectsoft Experience (Part 2) appeared first on Intellectsoft Blog.