Starling Bank cashes in on open source Kubernetes for flexibility and agility

UK fintech Starling Bank is building on the evolution of its architecture with plans to move to a cross-cloud approach supported by open source container orchestration platform Kubernetes.

The apps underpinning the bank's mobile-first operation are built for the cloud. Consumer devices talk to Starling's back-end, which is primarily implemented on the Amazon Web Services (AWS) platform - the company also uses cloud services provided by Google as well as Azure, to a lesser extent.

According to Starling Bank's chief technology officer Greg Hawkins, the cloud approach enables the bank to overcome many of the technical hurdles traditional banks face when introducing technology designed to assist a digital transformation while also complying with Open Banking requirements. He says:

We weren’t held back by having to do capacity planning, sizing on datacenters or anything like that. While our competitors based on white-labeled existing banking back-ends had difficulties with release cycles, getting bugs fixed and so on, we were building new and innovative things. With cloud you can essentially dream what you need into existence and get going right from the start.

Since Starling released its first production account in early 2016, the team has worked on incremental improvements to its set up and was able to deliver on the Open Banking concept introduced by PSD2 rules. As the new regulations will see customers be able to share their banking data with third parties via APIs, the fintech has stolen a march on its UK rivals by being the first to offer it to retail banking customers. Hawkins says:

It has been one sort of an uninterrupted race for us, we have been releasing feature after feature - and all of that was enabled by the fact that we were in the cloud.

Future evolution

According to Hawkins, Starling wants to focus on the "evolve-ability" of its cloud computing set-up. This, the executive points out, is about driving incremental improvements using the ability to deliver quickly, rather than necessarily getting it right the first time. He says:

If I have an idea of something I want to deliver, there’s nothing to stop me spinning up a hundred [virtual] servers to try something out. Typically in a legacy bank environment, you have to make a business case to acquire all the kit, and then once you got it, you may be sure as hell it works because of the money has been spent.

For Starling's architecture of multiple hosts and containers, automation seemed the obvious route to evolution. With Amazon's Elastic Container Service for Kubernetes, Hawkins hopes to make it a lot easier to move implementations across different cloud platforms. He says:

Once we are delivering our services on Kubernetes on Amazon’s EKS, it becomes much easier to move back and forth between Google’s Container Engine and potentially Azure as well.

According to Starling's CTO, the new approach helps to address regulatory challenges around reliance on a single provider of outsourcing arrangements. He points out:

Any UK bank has to have an exit strategy or plan on how they would transition away from any outsourcer. While AWS certainly understands this, we need to be continually aware of the level of dependence we have on them. Also, many things AWS offers us are commoditized these days, so they’re available similarly in Google Cloud and Azure.

Backups at the bank are made within the AWS cloud, but data is also encrypted and copied onto Google Cloud Platform (GCP) as well. Starling plans on moving services to Kubernetes this year, however Hawkins accepts that sophistication at the level of moving computing back and forth across different clouds is still something for the future. The CTO says:

Whatever happens, even if Amazon explodes, we’ve got our data safe somewhere. But moving to a point where you are running against a database in Amazon and you want to be able to transition the same data of the same service in GCP in a matter of hours is a little bit further for us.

Nonetheless, the CTO predicts it will become trivial to move computing between different cloud providers in response to emerging commercial conditions. In that scenario, cloud providers will become similar to APIs rather than infrastructure provision incumbents. Hawkins adds:

Similar to the Amazon facial recognition we’re using in fraud detection in customer onboarding, similar offerings are available from Google and from Microsoft as well. So we’ll be doing more and more of that.

Within the next year, Hawkins expects Starling will be doing a lot more work with Google, while Kubernetes will be running on both GCP and AWS. The CTO also foresees that its cloud architecture will have changed considerably: its APIs currently cover about 20 independent services; that is predicted to more than double before the end of 2018.

The majority of the software used by Starling is already open source, with tools including CoreOS, Postgres, ElasticSearch, and BigQuery, as well as Java for Android development and Swift for iOS. The exceptions are a couple of commercial licenses involved in the integration with a third party, as well as some commercial applications in areas like security.

Additionally, the bank is keen to do more around moving data between clouds for analytics. According to Hawkins, both of its main cloud providers are making great strides on data science and machine learning offerings and Starling wants to be able to apply that to its business.

On other cloud-related trends, Starling will be looking into evolving serverless as well, though in a smaller scale as the IT executive considers there are a few questions around the model's application to the firm's needs that are still "harder to answer."

However, the bank is already using AWS Lambda to automate various tasks and escalating privileges of developers for doing releases and will continue to do so, particularly in the cross-cloud case around tooling or deployment.

Open Banking and the cloud

While the increase in data volumes predicted as a result of the introduction of Open Banking is concerning for some, Hawkins says that his cloud-based set-up means this is not the main issue for Starling as AWS and the firm's other cloud providers offer effectively limitless capacity. He says:

If we need more capacity we just request it and sometimes we don’t even have to: if we got auto scaling for something then we might find that after a certain level of CPU is crossed, we automatically provision new boxes. That’s not to say that any architecture doesn’t have its bottlenecks, but as you grow you discover those and reengineer things to cope with whatever you need.

The main impact of PSD2 is to allow customers to expose their data selectively to third parties and delegate tasks such as payments. This in turn raises a debate around security. Hawkins says:

PSD2 opens up some interesting security questions which we've been developing responses to over the last year since we delivered our API implementation in March, way ahead of other banks. It's about ensuring delegation works safely, reliably, quickly and revocably and over the past few months we've come up with the way we want to categorise the different tiers of access and apply the appropriate security measures for each.

Cloud-based from scratch

To build and develop Starling's cloud estate, Hawkins was keen to recruit an experienced team that was not restricted to bankers - while many of the team came from firms like Barclays, Goldman Sachs and JP Morgan, there are also several former employees of technology companies such as defunct cab-hailing firm Hailo, eBay and Amazon itself. Defining the core mantras for the architecture from the start was also crucial. He says:

We have adopted a few key principles for the way in which we constructed our architecture: it had to be based on self-contained, autonomous, independently deployable services, so if any [systems] go down, we can mitigate gracefully. It also had to be an architecture spread across defined availability zones, so if there’s any hardware failure, our customers won’t even notice.

According to Hawkins, the fintech's positive experience with cloud computing is helping to change old attitudes about whether the approach is appropriate for mission-critical environments. He points out:

As much as cloud has facilitated our build, certain aspects of it naturally encourage the development of an architecture which is targeted at resilience and scale - which is something that has been very important to us from the start.

The belief that only mainframes can cater for the needs of a bank is not only wrong but dangerous, says Hawkins. But according to the CTO, the debate is not about what goes in mainframe or in virtual machines in the cloud, but the techniques and methodologies that come along with legacy hardware and architecture. He says:

For example, it's very hard to do test-driven development on mainframes, as well as doing continuous delivery - not to mention the [limitations of] use of agile practices in some of those environments. And then when things do go wrong you see things like the big RBS overnight batch issue a few years ago, when it took weeks until some of the customers actually had a clear view of what money went in their bank accounts.

The downsides of cloud

While cloud provides a range of advantages, it's not all plain sailing, with some of the downsides relating to aspects that are out of the end user's control. To illustrate such situations, Hawkins mentions the issue AWS had during February 2017 in one region in the United States. He says:

These things do happen occasionally and when they happen, you sit there waiting for AWS to fix something. This is arguably a better place to be than having to work to fix it yourself, but nonetheless there’s not a great deal you can do.

It is stressful to depend on a third party for a large part of the quality of service to final consumers. However, Hawkins points out that this is more to do with outsourcing relationship management rather than anything, in particular, to do with the cloud.

We have built such a resilient architecture that large bits of our estate can effectively disappear or go very slowly but we can still deliver a very good service to customers.

Another difficulty is related to connecting with various third parties as part of Open Banking, with many not being as cloud-friendly as Starling. According to Hawkins, some of these companies might even require hosting of physical kit to enable the connection to their API platform.

We will see how that goes in future, but working with legacy third parties from the cloud can definitely be challenging.

My take

Starling Bank is a business that reflects the modern approach to development.

While large incumbents debate whether cloud-based technologies are the direction to take, challengers like Starling Bank are treating cloud as a commodity and talking about Kubernetes as the development innovation du jour, supported by a large community of interest.

Kubernetes, with support from Amazon, Oracle, Microsoft, Red Hat, VMware, SAP, and Oracle (along with more than 1,400 contributors) represents an environment that provides developers numerous choices that fit well with different deployment methods. In that sense, it's a no-brainer.