FintechOS Cloud (for v.21.x)

This document provides detailed information regarding different scenarios for FintechOS deployment in the FintechOS Cloud.

Summary

Base tiers

Base tiers include Dev and UAT environments.

Infrastructure monitoring and security operations include active monitoring tasks, continuous improvement, component updates, as well as security and auditing for infrastructure resources. They do not include platform upgrade tasks, application support, and application incident management.

A QA environment is not available on the Basic tier.

Analytics add-on 

Using FintechOS features, you can enable everyone at every level of your organization to make confident decisions using analytics using unified data from many sources and create interactive, immersive dashboards and reports that provide actionable insights and drive business results.

Required capacity should be estimated based on customer requirements, number of reports and users.

The pricing tier required for Power BI capacity depends on 

• The data models you are using 
• The number and complexity of required queries 
• The hourly distribution of the usage of your application 
• Data refresh rates 
• Additional usage patterns that are hard to predict. 

Other Add-ons

Category	Component
Additional FintechOS components	Additional Portal
	B2C unauthenticated Portal
	OpenAPI
	JobServer
	Service Pipes
	Data Pipes
Custom Element	App Service
	Container Instance
	Database
	EventHub
Infrastructure	Permanent secure connectivity
	Continuous Monitoring
PowerBI	Embedded
UpScale	Performance improvement
DownScale	Cost optimization

 

Additional portal

This component it is required if you need more than one user authenticated portal. Usual cases are those in which internal users are acting as operators or supervisors and you need to provide services to external parties (partners or clients) using an authenticated front-end. Each portal can have its own identity provider and you can have a clear separation between internal and external users. Also, you can set different access rules (internal access only vs public access).

By default, all tiers contain one FintechOS portal which can deliver any authenticated Digital Journey. In some cases, multiple portals are required based on the business case and security requirements.

Example: One platform deployment can use one internal portal (available for company users only), one external portal which offers a publicly available solution, and one portal for partners, exposed in internet but restricted based on the source IPs. Each portal can use a different authentication method and user store.

Additional portals are offered as an add-on to the default baseline model.

B2C unauthenticated Portal

FintechOS can offer unauthenticated user journeys as an additional feature, in order to allow users to perform different Journeys without requiring a personal account.

Unauthenticated portals are required when you want to expose a front-end which can be accessed without requiring user credentials. Usual cases are onboarding portals or loan/insurance portals in which a user can create an account or buy a product.

Job Server

This component is required to trigger asynchronous tasks based on the input provided by platform components, for example: generate a contract in the background and trigger external APIs, check for specific information by running queries on external services, run overnight jobs, etc.

Open API

Exposes platform APIs to external services using a standard language. It is used when you want to expose platform functionalities to external services such as customer internal services.

Data Pipes

With broad access to more than 250 enterprise data sources and counting, CData enables seamless data access to every major Accounting, CRM, ERP, Marketing Automation platform, Go to source categorization, Collaboration tool, API, database, or data warehouse. The CData Sync service is required for the FintechOS Data Pipes data replication feature. If you have multiple platform instances, the service is shared between FintechOS instances and it should be installed only once.

Service Pipes

The services pipes add-on is required to integrate with external data sources and it brings additional features as parallel processing, fast integration, standard configuration available for well-known services (e.g.: PayU).

Custom Element

In order to satisfy any custom requirements, additional services can be deployed as requested by customers, usually to host services which are not part of the FintechOS platform but are required to complete the solution.

Adding custom elements is only available for FintechOS Enterprise tiers.

We can provide the following types of resources as custom elements:

• App services (PaaS deployment of a web server)
• ACI – Azure Container instance
• Database in PaaS model (database as a service)
• EventHub - Azure Event Hubs used for the data streaming platform. It is required if the customer wants to integrate with its own Continuous Monitoring solution (e.g. QRadar)

Permanent Secure Connectivity

A site-to-site permanent secure connectivity can be added to our FintechOS Cloud deployment model and it is required for private/secure communication between the FintechOS environment and customer on-premise services. It is usually required to access the platform by internal users via private networks without internet access or to secure access to on-premise APIs/services from the FintechOS environment.

Two permanent secure connectivity tunnels are included if you opt for the permanent secure connectivity add-on feature, one of which is used for development and testing environments while the second one is used in production.

Communication security to and from FintechOS is also achieved by encrypting traffic with SSL certificates, so that traffic always goes through the HTTPS protocol.

FintechOS makes it easy to protect applications through a custom domain with SSL certificates. Customers can choose between using the default FintechOS cloud certificate free of charge or providing their own certificate.

The FintechOS certificate is emitted by a Trusted 3rd party Certification Authority and can be used both on the server and as a client certificate when integrating with external services, depending on the external service's requirements/limitations.

Continuous Monitoring

Based on Azure Sentinel, FintechOS can offer a continuous monitoring solution for the customer specific platforms. The continuous monitoring solution is usually required to comply with custom or specific regulations and it can help organizations to have a better overview on the security of the platform by providing dashboards, alerts, and security analytics.

Performance boost

If the chosen FintechOS tier does not offer desired performance, we can offer additional performance improvement within specific limits.

The performance boost gives an additional 10 users and ~20 hits/sec for basic and standard tiers and 20 users with 50 additional hits in Enterprise tiers.

Cost optimization

Higher tiers, by default, offer additional security and availability features as well as better performance in terms of compute power. Some solutions do not require too much compute power but are required due to regulations (laws or internal policies), security, and availability features. In this case, we offer a downscaled environment with the same features.

Common Environments for all Customers

Regardless the chosen deployment model, FintechOS Cloud tiers contain multiple environments:

• The Development environment which is used by internal teams and customer technical teams to create, customize, and add features on FintechOS to achieve desired functionalities.
• The QA environment is used to test all developed functionalities and deployment features before migrating to the UAT environment. The QA environment is not available in the Basic tier.
• The UAT environment is used to provide a test platform for customer.  The main purpose of this testing is to validate the software against the business requirements. This validation is carried out by the end-users who are familiar with the business requirements.
• Production environment

Development and QA

Development and QA environments do not require a specific architecture or performance as they typically use dummy data and are not critical in terms of availability.

UAT

For end-to-end testing scenarios with best results, the UAT environment should have the same architecture as the production environment. However, for cost optimization, UAT environments can have a lower performance and do not need the same monitoring and alerting features since they are not critical for the solution's availability. Also, backup policies can be limited to an acceptable minimum.

Production

In a production environment, regardless the performance required for running the load, a minimum size for infrastructure components is required to achieve the security and availability standard required.

Generic Deployment Models

Single Region

Azure PaaS services are used to deliver services and high availability, balancing, and backup capabilities. They are offered by default by the Cloud provider using state of the art technologies.

Dual Region Deployment

Azure paired regions are used to deliver high availability, best performance and data resilience for Enterprise and Enterprise Plus models. Databases are continuously replicated between regions and, if one region is affected by a disaster, the solution will be immediately available in the secondary region.

Common Features Offered in Production Environments

Category	Features	Basic	Standard	Enterprise	Enterprise +
Availability	Backup Services	✔	✔	✔	✔
	Redundancy	Single Region	Single Region	Multi Region	Multi Region
	Disaster Recovery Model	X	Backup based	Manual failover	Automatic failover
	RTO*	X	12h	2h	1h
	RPO**	X	15min	15 min	5 min
	Failover Model	X	X	Manual Failover	Automatic Failover
	SLA	99.77%	99.77%	99.99%	99.99%
Performance	Performance enhancement	X	✔	✔	✔
	Performance model	Basic	General Purpose	Business Critical	Business Critical
	Concurrent users	15	50	80	80
	Response time	<5 sec	<5 sec	<5 sec	<5 sec
	Number of hits/sec	25	50	75	75
	Adaptive performance	X	✔	✔	✔

*Maintenance windows not considered in the assumed RTO plans.

**RPO is 100% backed up for the database, which contains critical data. Storage account files are stored on the Azure Storage account and have an RPO of 15 minutes as stated by Microsoft. However, there is no SLA delivered by Microsoft for storage account RPOs, therefore FintechOS cannot guarantee the storage account RPO.

Feature Descriptions

Availability

Backup Services

FintechOS simplifies workload protection with built-in backup capabilities for customer data by default, with scalable backup solutions based on your storage needs. The centralized management interface makes it easy to define backup policies and protect your data.

Redundancy

All environments offer a redundant model and, depending on the FintechOS tier, you can benefit from a redundancy model suitable for your workloads.

In Basic and Standard models, your data is kept in a single region. Basic models keep data files and databases in a locally redundant storage which means your data is synchronously copied three times in a single physical location in the primary region. In the standard mode, your data is copied across three Azure availability zones in the primary region. 

Enterprise and Enterprise Plus models offer durability of data even in case of a complete outage in the primary region by replicating your data to a secondary region.  The data is replicated asynchronously to a single physical location in the secondary region. Within the secondary region, your data is copied synchronously three times in the same location.

Disaster Recovery Model

DR is included as a service along with Standard, Enterprise, and Enterprise Plus models. The Standard Disaster recovery model is based on backups, and it can restore the entire environment to a secondary region which is hundreds of miles away from the primary region. In case of disaster, all your services will be provisioned using predefined automated scripts in the secondary region and data will be restored based on the latest backup information available according to backup policy.

Enterprise and Enterprise Plus tiers keep the secondary region up and running, with all your services and data available in case of disaster, based on asynchronously replicated storage and databases.

In case of disaster, there is always a risk of data loss because services are not available, and data might be compromised without control.

RTO (Recovery Time Objective)

This is a measure of how long it takes to do the failover in different scenarios. The failover time depends on several factors including database RTO, storage account RTO, and DNS switching time. FintechOS has dependencies on the underlying infrastructure and the RTO time is backed up by Microsoft services. Also, a fully functional environment might have dependencies on the customer integrated services which are not covered by the RTO provided by FintechOS.

The RTO time calculation starts when a Disaster is acknowledged, meaning the services are not recoverable in the current region and in the desired conditions.

The standard environment recovery model RTO depends on the provisioning time for resources in the secondary region, DNS switching time, database RTO, and storage account data.

Enterprise models offer a better approach by having the secondary region services already available and data replicated asynchronously. In case of disaster, failover is manually triggered based on the DR committee's decision. This approach has advantages as there is a better control on the data, and we can decide the acceptable level of data loss. However, while the decision is made, the recovery time is affected.

The Enterprise Plus model offers automatic recovery in case of disaster. In this model, both environments are available and switching between environments in case of disaster is fully controlled by Microsoft as follows:

• Traffic is routed to the secondary region based on predefined health probes.
• The automatic failover policy is configured for database services and any outage that impacts databases results in automatic failover.
• Storage account failover is based on Geo-replicated storage and, in case of disaster, failover is fully managed by Microsoft services and policies.

Due to Microsoft constraints, and the fact that Microsoft does not have a commitment regarding storage account recovery time, recovery of files might take longer than expected. However, this should not affect environment functionality since file data should not impact application functionality.

RPO (Recovery Point Objective)

RPO is a measurement of the time from the failure, disaster, or comparable loss-causing event. RPOs measure the most recent point in time when your data was preserved in a usable format, usually the most recent backup or successful replication. Recovery processing preserves any data changes made before the disaster or failure.

In FintechOS, the RPO is determined by the database and storage level data.

Standard tier RPOs are based on backup frequency for database and geo-replicated storage data. The Enterprise and Enterprise plus tiers use full replication mechanisms for data and storage, offering better RPO times.

While the databases have a clear replication SLA provided by Microsoft, storage account replication is stated to be at 15 minutes, but is not backed up by contractual SLA.

Failover Model

For Enterprise and Enterprise Plus tiers, a secondary region is already provisioned and is ready to accept workloads. In case of disaster, a failover and switch to the secondary region can be performed. Failover in the Enterprise tier is performed on demand based on a business decision related to the impact level of the disaster in the primary region. Enterprise Plus offers automatic decisions based on health probes and additional criteria such as downtime, switching the entire workload to the secondary region.

Forced failovers are consequence of a disaster and may result in data loss considering the asynchronous replication mechanisms. Estimated data loss is based on the RPO (Recovery Point Objective) detailed above.   

Performance

Performance Enhancement

All FintechOS environments are based on Azure PaaS services to offer state of the art technology to host your services while giving you the best cost/performance balance. Standard, Enterprise, and Enterprise Plus tiers provide enhanced performance using the premium level of the same service to host FintechOS workloads.

Performance Model

Basic performance models offers a startup pack with features required to run the application in good performance conditions.

General Purpose models are designed for applications with typical availability and common IO latency requirements, and have improvements as auto-scale and premium tier resources for front-end workloads.

Business Critical tiers are the optimal choice for mission-critical workloads offering the highest performance tiers, lowest latency, auto-scale features, and additional high availability measures based on state-of-the-art underlying technology.

Adaptive Performance

With adaptive performance, you are never worried that the system will block during peak intervals. The production environment is configured to increase performance based on predefined rules related to performance metrics as CPU or memory usage. FintechOS front-end components are configured to automatically create additional nodes (scale out) when performance drops below predefined criteria.