Long before Covid-19 hit, banks had always looked to have agility and adaptability when it came to their systems. Whether to cater for known customer demands, such as “Cyber Friday” in the US or the end of the UK ISA season, or to allow new products or services to be rapidly rolled out. The need for this agility and adaptability has been brought to the fore during the pandemic as banks needed to quickly stand up new services – whether to serve customers or enable colleagues to continue to work remotely.
Within the banking sector, pretty much every firm has started to leverage the public cloud to deliver services – both in development, but also for production. As firms embark on leveraging a range of public cloud services, they are often drawn to how they are able to scale services up and down, quickly provision and resize instances, as well as programmatically drive the environment as code. Firms start to quickly drive value from leveraging tools such as Ansible and Terraform to enable configuration management, to standardize and automate deployment and configuration of workloads. Embedding these tools into larger tool-chains also drives value when it comes to adopting DevOps ways of working, along with only needing to provision workloads when they are required vs the more traditional approach of having servers idle for long periods of time even if they aren’t being utilised.
Whilst many firms have adopted suitable operating models to get the best out of the public cloud, they too often become “accidently hybrid”, and end up running two personas. The first persona, is driving their cloud based services with a modern mindset (i.e. elasticity, programmatically etc). The second persona is a more legacy mindset, where they continue to drive their on-premises environments with maybe some scripting for provisioning and patching, but without any of the other benefits they are getting in the public cloud. In this second persona, the technology and also the teams responsible for it are also typically siloed (i.e. focused on compute, storage, networking, middleware, databases etc). This results in a number of inefficiencies and also acts as a barrier to leveraging the successes learnt in the public cloud on-premises.
The 2020 Flexera State of the Cloud Report highlights that 93% of enterprises have a multi-cloud strategy, with 87% having a hybrid cloud strategy. Whilst these figures aren’t broken down into industry segment, this certainly fits what I see across the banking sector. However, how can those banks that want to run a hybrid cloud operating model ensure that it isn’t “accidental” and is deliberate and incorporates the best of both worlds? Firstly, they need to ensure that the technology platforms deployed on-premises are able to be driven in the same way as you can drive the public cloud. With flexibility, agility and by code. A great example of how this can be achieved is with an architecture known as “Composable Infrastructure”.
Composable Infrastructure builds on the principles of Converged Infrastructure but brings more flexibility through the ability to dynamically reallocate resources on the fly – for example, you might want to point a number of infrastructure resources at App A during the day, but reallocate these resources to App B at night. Composable Infrastructure lets you do that.
In traditional deployments, infrastructure stacks are siloed with separate architectures for networking, storage and compute. This creates inefficiencies where infrastructure resources are underutilised and management of all the different silos can be complex. With Composable Infrastructure, the networking, storage and compute are all brought together into the same architecture – providing software defined flexible pools of resource. More importantly, Composable Infrastructure allows an organisation to drive the infrastructure via code, utilising API’s that are available for tools such as Terraform or Ansible to consume. For those new to Composable Infrastructure, this is a great video to watch.
As highlighted by Gartner, Composable Infrastructure provides the most benefits when:
- Resource consumption is unpredictable
- You need to leverage high-cost components such as GPU’s
- You want to drive a high degree of automation
- You want to offer self-service resource deployment
Composable Infrastructure isn’t just for virtual machines either. It is able to handle mixed workloads, such as hybrid cloud platforms (e.g. Google Cloud’s Anthos), container platforms (e.g. Red Hat OpenShift) or even private cloud platforms (VMware Cloud Foundry) all running on the same architecture stack.
Focusing away from the technology, the trickier aspect when it comes to avoiding being “accidentally hybrid” is when it comes to your people and processes. Those banks that truly succeed in getting value from a hybrid architecture are those that not only have an operating model that spans both hosting environments, but that have also matured and evolved processes to cater for driving benefits regardless of the hosting environment.
Within the banking space, leveraging Composable Infrastructure not only enables a consistent operating model across on-premises environments and the public cloud (with the benefits of single toolsets, along with consistency and repeatability), but also offers the crucial flexibility and adaptability that banks need. Similar to how workloads can be spun up on demand and terminated when no longer required in the public cloud, the same is possible in on-premises. An example of this could be utilising an environment to serve VDI workloads during business hours, and then overnight turning it to serve Grid Compute requirements.
Most firms would agree that the world is hybrid; many forget however that to truly deliver the agility and adaptability you need to thrive in the changing world we find ourselves in, you must remember to deliver the “cloud experience” on-premises too.
Chris Ibbitson
Hewlett Packard Enterprise
Chris_Ibbitson
Chris is a Chief Technologist for HPE, focused on the Financial Services industry. Before joining HPE, Chris has worked at both a Global Systems Integrator, as well as at a Global Bank in a variety of senior architectural roles.
