Back to Cloud Native


Cloud Native Blueprints for Banking

A Team Perspective by Jared Ruckle, Ford Donald, and Guillermo Tantachuco of VMware





Secure, Hybrid Banking Reference Architectures for Cloud Native Applications

Cloud native patterns and practices help banks release high-quality software faster. This in turn, helps the business get a leg up in the market. In banking this translates into the following:

Industry Trend
Cloud Native Advantage
Rising consumer expectations. Consumers now expect always-on access to their financials. They want it delivered in real-time, across many different devices. They want online banking, via self-service. This can be a challenge for banks, especially those that still depend on legacy tech up and down the stack. Investment banks face many of these same challenges. With a cloud-native application, the priority is an API-first design. Developers can deliver features to users across across many devices. Great APIs also deliver a zippy user experience.
Increased competition from FinTech. Software is eating the financial services industry. Startups are gaining market share on the strengths of their software. They can rapidly improve it based on customer feedback. These startups have many advantages compared to incumbents. A better culture, leaner processes, and a lack of technical debt to name a few. We’ve seen this disruption pattern play out in many industries the last 5 years, and now it’s happening in FinServ. Three things help you become a software-defined business. First, a microservices architecture. This encourages rapid iteration, and small changes to discrete components of a system. Next, continuous delivery gives developers a frictionless path to production. This leads to frequent deployments of small changes that add up to big benefits over time. Finally, a DevOps culture eschews traditional developer and operator roles and objectives. Instead, the goal is to deliver value to the customer.
Regulatory requirements & compliance. IT systems, processes, and applications need to keep pace with a tidal wave of industry regulations and compliance standards. That demands significant time, attention, and budget. Cloud-native approaches prize automation and a “securityfirst” approach to feature design. These two points are crucial to compliance. Highly automated systems log every activity. It’s easy to see what changed, when, and who triggered the update. Further, automated systems can be rapidly patched and updated with new bits often. And automated systems generally need much less day-to-day human involvement, boosting security.

“Security first” means that engineers design security into features from the start. They are not bolted on later.

Security. The threat landscape is constantly evolving and changing. Banks must contend with malware, advanced persistent threats (APTs), and the specter of leaked credentials. Conventional wisdom within enterprise security circles advises “go slow to reduce risk. In the cloud-native world, it’s “go fast to reduce risk.” Why? Systems that change often are far less vulnerable to malware and other threats. Static environments are where bad actors thrive, and wreak havoc on your enterprise.

Use automation to rapidly apply the latest patches to systems. Embrace immutable infrastructure concepts and re-deploy your stack to a “last known good state” often. And rotate credentials often, so that any leaked creds quickly expire and become worthless.



How Do Banks Go About Becoming Cloud Native? It Starts with a Platform.

Many banks adopt self-service platforms to help teams deliver software continuously. Why? A platform provides a consistent, predictable, and secure way to deploy and run apps. Platforms deliver crucial features to developers in a unified self-service model. In other words, platforms hide the messy details of a very complex set of IT capabilities.

At its best, a platform is the boring and reliable presentation of all the features your teams need. Capabilities are accessible in a way that is fast and simple for its consumers. Platforms provide these capabilities as fully-automated “dial-tone” that just works. Every application team can easily consume platform services on their own. You can imagine the economies of scale with platforms. The more apps you run on a platform, the more efficient it becomes for the organization, and the more value it provides.

When an organization goes “all in” on the right cloud native platform, everyone wins. Developers, operators, and finance teams all realize massive gains.


Reference Architecture: Sample Customer Banking App

The following sample application was the result of a deep collaboration and co-engineering between VMware and a strategic banking customer. This application is an enterprise data platform. It acts as data source for all other services to get reference data. We can see how the platform enables the developers to focus on their custom code. VMware Tanzu and Spring Cloud Services take care of ongoing management and operation.


Reference Architecture for Data Ingestion based on Spring Cloud Stream



This co-architected application features 14 custom services. Meanwhile, VMware Tanzu manages the underlying infrastructure and runtime dependencies. The platform also handles essential elements such as config server, service registry, circuit breaker dashboard, and app autoscaler.

The team’s white paper encapsulated several more learnings as reference architectures.


More from the Team about Cloud Native

Secure Hybrid Banking Reference Architectures for Cloud Native Applications



Back to Cloud Native