Given perceived risks, the security and cost benefits of moving to a cloud-based system were often overlooked, with some financial institutions believing that cloud deployments will result in more overall risk than traditional systems. However, over the
last few years, the more a bank takes the time to understand the cloud services available, the bigger the benefits will be.
Finextra spoke to Josh West, senior principal solutions architect, global financial services, Red Hat, about how reaching economies of scale – achieving cost advantages that can be obtained due to scales of operation – is of paramount importance.
What must be considered when choosing a public cloud provider?
The largest banks are still early on in their process of migrating to public cloud and one of the top considerations is how the ways of working can be changed, when, 20,000 – 50,000 people within these firms have been delivering technology in the same way
for quite a long time. For this reason, when considering which public cloud provider to choose, it is not only cost that must be considered.
Banks must also weigh up how to empower the most productivity and efficiency to the masses of employees that own these applications and serve business functions. Changing technology just for the sake of having different infrastructure is not recommended.
Moving to public cloud should be done with the intention of providing innovation and connecting employees with new, digital ways of working.
West explained that while AWS “does a good job of providing the key factors and methodologies, such as cost, performance, scalability, elasticity across its well-architected framework, most public cloud providers are aligned with the same capabilities across
the ecosystem. Individual teams, however, are focused on the running costs of operating an application continually as it scales and managing security.”
He also mentioned that “when an individual team is trying to move to public cloud, and they have multiple choices, they must consider which one has the unique capabilities they're looking for cloud-first strategies for applications are retargeting AWS or
Azure depending on the first big commitment in these firms for general capabilities. What we see is capital markets has been leaning towards Google Cloud due to their strong maturity and focus on data capabilities.”
As highlighted by West, there are many “different forces at play”. He continued: “Enterprise architecture review boards look at the entire estate of a firm many times, particularly around the divisions that are trying to improve business growth, get the
funding to do new development, and really innovate their applications.
“The CIO and CTO will then push out a strategy that states that they are cloud-first. Anything else is an exception. Most of the firms over the last several years have said that we’re migrating to AWS, or to Azure, but we are now starting to see that change
and firms are introducing multiple clouds,” West added.
At the application owner level, constraints need to be clarified. These individuals and teams will need to consider their applications and determine how they can best natively adopt that technology. In West’s view, there is no clear route to the cloud for
an application, because CIOs and CTOs are continuously pushed to migrate to the cloud, regardless of whether they have the budget and bandwidth to renovate while adding new business capabilities and top line growth.
Sometimes, business leads ask their technology teams to utilise new models – there is a lot of push and pull across quite a few different scenarios and situations. On the other hand, “developers want to update their resumes and show hot experience. Sometimes
it’s mandated, sometimes it’s the way to go, and if you have funding, you should be using this newer cloud model for development and SRE oriented operations,” West said.
How can a bank achieve economies of scale? What kind of platform is required?
Where do the economies of scale come in? West agreed that there are some organisational and structural challenges within a bank, and while the institution will want to own a large transformation, “you end up with different leaders owning each individual
public cloud and pushing or pulling in a particular direction.”
What this results in, as West explored, is that each one of these teams end up fighting for resources and the same engineering is completed multiple times. “We’re seeing this play out in real time right now in the industry, where financial firms have these
big commitments to at least two, if not three clouds in tens to hundreds of millions of dollars, for each provider.”
One single distribution of Kubernetes can dramatically reduce fragmentation and the number of times the same tasks are completed and operate consistently on all public cloud providers – whether it’s AWS, Microsoft Azure, Google, Oracle, or other smaller
pay as you go host providers for edge sites, such as Equinix, or on-premise appliances, such as Dell APEX. A platform such as this can also support banks in building and deploying, blending the commitment models so that a foundation is established that is
cost effective in terms of technology and organizational efficiencies.
The reality is that while some applications will need to be decommissioned, others will need to be reinvented. However, to a large degree, the first step is to ensure applications are in a state where they can deliver faster and can be iterated upon in their
current state too. The location and underlying provider do not matter as much as moving to new ways of working.
How can a bank decide which applications will need to be decommissioned and which need to be reinvented?
Application selection for modernisation is focused on the speed of change needed to keep pace with the business capabilities, the ability to run business experiments as the markets change rapidly, and what is still relevant over the next three to five years.
In West’s view, “while moving to cloud is about changing the pace of response to business needs and the scale necessary, the developers and operators are constrained by maintaining the stakeholders’ needs. On the technology side, there are innumerable considerations
for maintaining security posture, external and internal access control, data sovereignty, data integrity, resilience, scale, evidencing of controls for regulatory bodies and so on that the technical staff can access, learn, experiment, through mastery with
a consistent self-service experience.”
To ensure this, banks may need to work with multiple public cloud providers to blend cost models, reuse commitments, and provide consistent on-edge networks. The future of banking will see a substantial mix of cloud providers over a long period of time –
it will not be one cloud or another.
According to West, looking back to two or three years, “much of the software industry was a zero-sum game. A lot of vendors were fighting to win their position, and there were a lot of partnerships, but it wasn’t the same as it is today. Today, everything
is about partnerships and less friction.
“We all have the same goal of driving that transformation and innovation in cloud adoption these days, and that is showing in contract models. From our customer’s perspective, we will work together, and we want to see that alliance between two teams that
really are matched to your account.”
How long will it take for Tier 1 banks to go from 20% on cloud to 100%?
West stated that “a few financial firms are currently citing that 80% of their applications are on public cloud servers. Others are less than 20% of the way there. Ultimately, it’s unlikely that any financial firm ends up 100% on cloud. The historical structure
within the firms have led to fragmentation, which have so far slowed down most of their ambitions of getting to cloud fast.”
Most firms still have over 10,000 applications to modernise, each with hundreds of components, still on premises. Some are finding the costs prohibitive, particularly those that have lifted and shifted to cloud without modernisation to higher level abstractions.
The advice for financial institutions is to move to the highest level of services available to manage cost effectiveness of cloud and an operational model that are optimised for Kubernetes and containers or above.
Dealing with inconsistencies and variations, particularly with Kubernetes across each public cloud provider introduces complexity and opportunity cost. Challenges can persist with the variation in underlying differences of the stack, update lifecycle for
Kubernetes, security and compliance controls, disaster recovery, data controls, and automation.
As financial firms restructure their organisational chart and multiple public clouds are enabled by a single ‘Platform Engineering’ hierarchy, the forward-looking strategy has provided consistency of experience, governance controls, and implementation in
overlapping capabilities such as Kubernetes and Linux.
West reiterated that “historically, infrastructure teams have been centrally focused on constraints, governance, and preventing insecure or immature practices. The new realities, instead, bring a newfound focus on reducing friction and aligning teams to
enable speed of adoption and modern architectures.
“This is done by creating platforms that empower people with prescriptive defaults to meet regulatory compliance, resilience, scalability, security, observability, governance needs, communities of practices sharing patterns, and inner-sourcing contribution
models that crowdsource the platform updates with a centralised stewardship - much like how open-source projects function.”
Historically, workloads were only considered in terms of size and how many cores, or resources, it used, but applications are so much more complicated than that – even a minor change can impact the business. Teams across the business must be engaged with
application developers to restructure, reenvision and redesign, for the future. Platform-as-a-product models prioritise consistency, optionality, speed of change, self-service, continuous cost optimisation, and safety and soundness.