Hybrid Cloud Architecture for Banks

#hybridcloud #cloudarchitecture #bankingsolutions #azurecloud #microsoft

Background

With the fast change of the digital topography for the banking and financial industry, organizations are increasingly looking at flexible solutions and partner ecosystem they can straightaway utilize with rapid ramp up time. As user base, transactional complexity, and extended integrations increases – data ingestion also surges exponentially, banks are requiring fast, innovative, and secure ways to serve, store, analyze and recover with the help of important data and underlining infrastructure.

Banks should not be worried to embrace the cloud, but they should take a hybrid cloud approach to get the maximum out of this technology. A hybrid cloud can offer the agility and scalability bank needs to keep up with the evolving demands of their end-customers. In addition, it can benefit them to conform with specific regulatory requirements, while still preserving control over their data and applications. By following the best practices outlined in this architecture, enterprise can ensure a successful execution of a hybrid cloud strategy.

Here are the ways hybrid cloud is facilitating banks metamorphose:

• ?Greater Flexibility: Hybrid cloud aids banks manage budgets with greater elasticity by simplifying a switch from fixed to variable costs. This move permits banks to focus on financing business schemes rather than securing investments in non-performing physical equipment’s.
• ?Market Agility: As the velocity of transformation in banking carries on accelerating, hybrid clouds support market swiftness, business scalability, making it affordable and easier to test new competitive strategies, while regaining more promptly from dissatisfactory approaches.
• User Experience:?At a time when customers increasingly demand more compelling user experience, the infrastructure of the cloud can help make digital services steadier, allow more frequent enhancements, and thus, reduce frustrating errors.
• Extended Ecosystem.?Finally, adoption of hybrid cloud encourages ecosystem collaboration, supporting wide range of communication and synchronization with distributors, suppliers, agents, partners, financial advisors, customers, and other stakeholders. when leveraged holistically, can help connect these ecosystems to enable enterprises shape new engagement waterways with customers and transmute customer experiences.

Architecture

This reference architecture for a banking Operation shows a secure hybrid network that extends a bank’s private datacenter network to Azure. This is focused on microservices based architectures. All inbound and outbound traffic passes through Azure Firewall.

This architecture requires a connection to your on-premises datacenter, using either a?VPN gateway?or an?ExpressRoute?connection. Typical uses for this architecture include:

• Hybrid applications where workloads run partly on-premises and partly in Azure.
• Infrastructure that requires granular control over traffic entering an Azure virtual network from an on-premises datacenter.
• Applications that must audit outgoing traffic. Auditing is often a regulatory requirement of many commercial systems and can help to prevent public disclosure of confidential information.
• This architecture uses the?Azure Application Gateway Ingress Controller (AGIC)?for ingress control. Using Application Gateway to handle all traffic eliminates the need for an extra load balancer. Because pods establish direct connections against Application Gateway, the number of required hops is reduced, which results in better performance.

Workflow

The Architecture consists of following components and considerations:

• On-premises network: In this architecture, the organization has created a secure private network that connects the various branches. This private network is connected to their Azure virtual networks either by using a?site-to-site?connection or ExpressRoute.
• Hub virtual network:?The hub virtual network is the crucial point of connectivity to your on-premises network. It is a place to host services that can be consumed by the different workloads hosted in the spoke virtual networks

AppGateway Subnet: hosts Application Gateway WAF2

• Spoke virtual networks:?Spoke virtual networks are used to isolate workloads in their own virtual networks, managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers

AKS Subnet: hosts the AKS cluster

Data Subnet: hosts the database (SQL & Cosmos)

• Virtual network peering:?Two virtual networks can be connected using a?peering connection. Peering connections are non-transitive, low latency connections between virtual networks. Once peered, the virtual networks exchange traffic by using the Azure backbone without the need for a router.
• Web Access Firewall (WAF): Policy associated to the Application Gateway as the root level and HTTP listener level. The Policy is configured in Prevention mode and uses the OWASP 3.1 rule set and a couple of custom rules that demonstrate how to block requests when the query string or a header contain a specific string. You can create more sophisticated custom rules to whitelist or blacklist the incoming traffic to the Application Gateway Ingres Controller.
• VPN virtual network gateway or ExpressRoute gateway: The virtual network gateway enables the virtual network to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. For more information, see?Connect an on-premises network to a Microsoft Azure virtual network
• Network security groups: Use?security groups?to restrict network traffic within the virtual network.
• Azure Private Link: This?allocates specific private IP addresses to access Azure Container Registry, Key Vault and database from?Private Endpoints?within the AKS system and for external networks.
• Application Gateway Ingress Controller: This allows?Azure Application Gateway?to be used as the ingress for an?Azure Kubernetes Service?aka AKS cluster.
• Azure Kubernetes Service (AKS):?simplifies deploying a managed Kubernetes cluster in Azure by offloading the operational overhead to Azure. As a hosted Kubernetes service, Azure handles critical tasks, like health monitoring and maintenance. Since Kubernetes masters are managed by Azure, you only manage and maintain the agent nodes.
• Azure Policy: Azure Policy enforces standards and assesses compliance for targeted resources deployed to Azure.
• Microsoft Defender for Cloud Microsoft Defender for Cloud is a unified security management and threat protection system for workloads across on-premises, multiple clouds, and Azure.

?????Logging & Monitoring:

• Application Insights:?An extensible Application Performance Management (APM) service for developers and supports multiple platforms. It monitors the application, detects application anomalies such as poor performance and failures, and sends telemetry to the Azure portal. Application Insights can also be used for logging, distributed tracing, and custom application metrics.
• Azure Monitor: Provides base-level infrastructure?metrics and logs?for most services in Azure. You can interact with the metrics in several ways, including charting them in Azure portal, accessing them through the REST API, or querying them using PowerShell or CLI. Azure Monitor also offers its data directly into?Log Analytics and other services, where you can query and combine it with data from other sources on premises or in the cloud.
• Log Analytics: Helps correlate the usage and performance data collected by Application Insights with configuration and performance data across the Azure resources that support the app. This scenario uses the?Azure Log Analytics agent?to push SQL Server audit logs into Log Analytics. You can write queries and view data in the Log Analytics blade of the Azure portal.
• Microsoft Power BI:?is a collection of software services, apps, and connectors that work together to turn unrelated sources of data into coherent, visually immersive, and interactive insights.
• Prometheus: is a pull-based system. It periodically scrapes metrics from configured locations. Prometheus can?scrape metrics generated by Azure Monitor?or kube-state-metrics.
• Grafana:?is an open and composable observability and data visualization platform. Grafana helps you query, visualize, alert on, and understand your data wherever it's stored.

External storage and other components:

• Azure Key Vault:?stores and manages security keys for AKS services.
• Azure Container Registry:?stores private container images that can be run in the AKS cluster. AKS authenticates with Container Registry using its Azure AD managed identity.
• Azure SQL Database:?fully managed and intelligent relational database service built for the cloud. With SQL Database, you can create a highly available and high-performance data storage layer for modern cloud applications.
• Azure Cosmos DB:?stores data using the open-source?Azure Cosmos DB API for MongoDB. Microservices are typically stateless and write their state to external data stores. Azure Cosmos DB is a NoSQL database with open-source APIs for MongoDB and Cassandra.
• Azure Service Bus:?offers reliable cloud messaging as a service and simple hybrid integration. Service Bus supports asynchronous messaging patterns that are common with microservices applications.
• Azure Cache for Redis:?adds a caching layer to the application architecture to improve speed and performance for heavy traffic loads.
• Azure Functions: Azure Functions is a serverless platform as a service (PaaS) in Azure that runs small, single-task code without requiring new infrastructure to be spun up. The?Azure Functions Premium plan?adds the ability to communicate with Azure Functions privately over a virtual network.
• Azure Logic Apps:?is a serverless cloud service that lets developers schedule and orchestrate common task workflows with a visual designer. The power of Logic Apps is the connectors that integrate with a number of first and third-party services with little or no code.
• KEDA?is a Kubernetes-based Event Driven Autoscaler. KEDA determines how any container within Kubernetes should be scaled based on the number of events that need to be processed. KEDA, which has a variety of out-of-the-box scalers, supports multiple types of workloads, supports Azure Functions, and is vendor-agnostic.

Design Considerations

Highlighted some of the key consideration:

Microservices

A microservice is a loosely coupled, independently deployable unit of code. Microservices typically communicate through well-defined APIs and are discoverable through some form of service discovery. The service should always be reachable even when the pods move around. The Kubernetes?Service?object is a natural way to model microservices in Kubernetes.

API gateway

API gateways are a general?microservices design pattern. An?API gateway?sits between external clients and the microservices. It acts as a reverse proxy, routing requests from clients to microservices. It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate-limiting. For more information, see:

• Using API gateways in microservices
• Choosing a gateway technology
• In Kubernetes, an AGIC primarily handles the functionality of an API gateway.

Service object

The Kubernetes?Service?object provides a set of capabilities that match the microservices requirements for service discoverability:

• IP address. The Service object provides a static internal IP address for a group of pods (ReplicaSet). As pods are created or moved around, the service is always reachable at this internal IP address.
• Load balancing. Traffic sent to the service's IP address is load balanced to the pods.
• Service discovery. Services are assigned internal DNS entries by the Kubernetes DNS service. That means the API gateway can call a backend service using the DNS name. The same mechanism can be used for service-to-service communication. The DNS entries are organized by namespace, so if namespaces correspond to bounded contexts, then the DNS name for a service will map naturally to the application domain.

Data storage

• In a microservices architecture, services should not share data storage solutions (it has not been shown explicitly in the architecture diagram). Each service should manage its own data set to avoid hidden dependencies among services. Data separation helps avoid unintentional coupling between services, which can happen when services share the same underlying data schemas. Also, when services manage their own data stores, they can use the right data store for their requirements.
• Avoid storing persistent data in local cluster storage because that ties the data to the node. Instead, use an external service such as Azure SQL Database or Cosmos DB. Another option is to mount a persistent data volume to a solution using Azure Disks or Azure Files.

Critical monitoring design factors

• How to spread Log Analytics workspaces across different geographical regions or teams.
• Monitoring the workspaces themselves, as well as their workloads.
• How to charge back different teams to optimize overall costs.
• How to visualize and possibly archive collected data.
• Creating separate dashboards for operations, apps, and different teams.
• Giving leadership enough visibility into the right set of information

References

• Hub-spoke network topology in Azure
• AKS cluster with the Application Gateway Ingress Controller
• Implement a secure hybrid network
• Azure Kubernetes Service (AKS) microservices architecture
• Microservices architecture on Azure Kubernetes Service
• Patterns and implementations for a banking cloud transformation
• Enterprise monitoring with Azure Monitor