Why microservices are the future of banking


Paul Taylor, Chief Executive Officer, Thought Machine

If an engineer from Google, Amazon, Netflix, or even Spotify walked into Thought Machine they'd be immediately at home. We use the same tools. Our software architecture principles are common across all the enterprises.

One of the most vital things we hold in common is our devotion to microservices. They are key to creating resilient, powerful, scalable applications that are easy to update. Frankly, Google couldn't run Gmail, or Netflix run at all, without microservices. They are fundamental.

Banks are less familiar with microservices. And that is being polite. Banks are decades behind the cutting-edge in software. Microservices are something bankers need to learn about, and fast.

So here's a quick masterclass in what microservices are, and why they are revolutionary in banking.

Traditionally banking applications are built as a single entity – a monolith. All the code is bundled together – in vast, sprawling code-bases, so intimidating that engineers get lost in its labyrinth.

Microservices are the alternative. Instead of a monolith, applications are broken into small autonomous chunks called microservices. Each microservice runs independently, and can be managed by a dedicated team. The microservices talk to each other via APIs.

What you have is a network of small, self-sustaining units, working together to create a single application.

The beauty is the size. Each microservice is kept tight and well-defined. In Silicon Valley there's a notion that the team working on a microservice should be small enough to be fed by two-pizzas. The famed Two Pizza Rule. That's seven to ten people, depending on how greedy they are. True or not – it captures the belief that a microservice should be scoped tightly enough for a small team to manage.

For example, in Vault Core the kernel is composed of around 20 microservices. Each one has a small team that knows it inside out.

And there's more

But it's more than mere size. In technical terms, there's a long list of fantastic reasons for using microservices.

1) Microservices are robust. If a single microservice malfunctions it is the sole casualty. Other microservices are unaffected. Compare this to a monolith, where a glitch can bring down an entire system, and this ability to isolate and limit damage is a profound advantage.

2) Microservices are tidier. From a planning perspective, it's easier to map out an application when dealing with distinct parts.

3) The problem of scaling is solved with microservices. A bank needs to be equipped to handle peak demand. Maybe that is the moment payslips are processed on the last Friday of the month, or Black Friday when customers shop like crazy. This means mainframes are scoped for peak demand, which may only be used for a minute a month. The rest of the time the servers sit idle. Furthermore, the bank needs disaster recovery systems of the same size. It's catastrophically expensive.

Microservices scale individually. They sit on the cloud, and expand and contract individually according to demand. This eliminates wasted infrastructure. And massive spikes in demand can be handled flawlessly.

4) Updating microservices is easier. Of all the advantages, this is the one to highlight. Compared with monolithic architectures, the difference is night and day.

Here's why. A microservice can be updated whenever its team is ready. No waiting for other microservices to co-ordinate. Each team can work at its own pace (unless there is a change in their API affecting other microservices, but even then the impact is limited to the short list of relevant microservices).

This approach is so much better. Teams can now upgrade their microservice in small, incremental steps. Fixing errors is quicker: it can be identified quickly – the team will know which change triggered it, and the search parameters are limited to the microservice. Innovation is accelerated. And teams are happier as they control their own destiny.

Monoliths are a nightmare to update. Changes are rolled out in a single Big Bang upgrade every six months. Errors are painful to locate – engineers must navigate through hundreds or thousands of simultaneous code-changes to find the bug. As a result, engineers on monoliths become averse to upgrades. Time passes, and the monolith becomes more and more out of date. The next Big Bang update needs to incorporate an ever larger backlog of upgrades, making the leap ever more perilous. It's a vicious cycle, all too familiar with bank engineers.

Switching to microservices ends the cycle. It is possible to continuously and smoothly upgrade the application asymmetrically, with each microservice advancing at it's own pace.

5) Microservices can be upgraded with no downtime. A Green/Blue deployment means the upgraded version is released in parallel with the old version, and traffic redirected. Customer service is uninterrupted. If the change proves unsuccessful for some reason, the old version can be spun-up and traffic redirected back again, reversing the changes. No downtime.

By contrast, Monoliths must be taken offline – hence the dreaded notification from banks: “Our service will be offline for maintenance”.

Microservices at Thought Machine

Now here's a question we get asked a lot.

“If microservices are so great, why are they not more common in banking?”

There are two answers to that. The first is the archaic nature of banking software. Many banks are marooned on decades-old systems, built on obsolete principles. Upgrading these ancient systems is almost impossible. It's not merely microservices that are missing – it's the past decade of technology.

The second is that running microservices in banking is hard. Race conditions mean only precisely engineered solutions will work. Imagine an account with two holders, and each makes a withdrawal at the same time. A monolith handles this pretty well: the single architecture hosted in an on-premise data-centre means response times of 1 millisecond are achievable. Conflicts are thus rarer, and easier to resolve. Microservices, alas, are more prone to race condition conflicts. They are located across cloud centres: factor in the speed of light as a natural limitation, plus resistance in the fibre cable, and other issues, and response times may be 200 milliseconds to a second.

This is why microservices are rare in core banking. Legacy providers could not crack the problem.

Today, race conditions are solvable. But the technology is currently mastered by only a few organisations. Thought Machine is the world leader in core banking because of our commitment to engineering. Our core banking engine, Vault Core, eliminates race condition conflicts in a manner superior to any other microservice based banking system.

It's why Lloyds Bank, SEB, Atom bank and Standard Chartered, amongst others, are committed to Vault Core.

Regulation is another issue worth mentioning. At Thought Machine, we upgrade our microservices on a monthly schedule. Yes, in theory our teams could upgrade each microservice whenever they liked, as is the case at Amazon and Spotify. But our close work with banks and regulators mean we've adopted a predictable schedule, to ensure total compliance with all regulations and demands.

Again, our deep knowledge of both technology and banking allows us to work in ways our rivals simply cannot.

The benefits to a bank

In truth, the elegant microservice architecture of Vault Core operates out of view from the perspective of our clients. Vault Core is composed of microservices, but banks connect via a public API, and that gate is all they see.

We talk about “holistic consistency”. Banks are presented with a consistent API. The changes under the hood do not affect the interface used by banks. So it might be argued bankers can forget about microservices.

However, banks need to understand microservices. Both to design their own internal systems, and to comprehend the strengths of Vault Core.

Adopting Vault Core means enjoying limitless scalability. Demand can peak and trough, and Vault Core scales smoothly up and down, riding the waves.

With Vault Core banks are building on the strongest foundations imaginable. The robustness of our microservices architecture means we can update with confidence, eliminate errors, and implement improvements with no downtime, reducing risk by orders of magnitude, and all at a dramatically lower cost.

These are phenomenal advantages.

Google, Apple, Netflix and Spotify are built on microservices. Now, using Thought Machine, it is the turn of banking to benefit.

<< Previous blog
Next blog >>
Empowering our clients to accelerate their modernisation
Read this blog
Money20/20 Banking Infrastructure Summit: What to expect with a core modernization program
Read this blog
Money20/20 Banking Infrastructure Summit: Building a modern technology stack
Read this blog
To be ISO 20022 ‘ready’ is not good enough
Read this blog
Building a winning team with a strong culture
Read this blog
Domain-driven design and the future of payments
Read this blog
How does Vault Core compare to closed-box systems, and what does this mean for product development?
Read this blog
Introducing our Enablement Portal – a complete resource for support, knowledge and training on the Vault platform
Read this blog
The Integration Library: a growing collection of solutions with best-in-class technology vendors
Read this blog
Building a bank on top of kubernetes
Read this blog
From speech technology to banking
Read this blog
Strategic partnership with Lloyds Banking Group
Read this blog
Cloud computing will save banks billions. Here's how
Read this blog
A demand for COBOL expertise underlines the fragility of critical infrastructure
Read this blog
Why are cloud systems so much more reliable?
Read this blog
Life may have slowed down but innovation doesn’t!
Read this blog
Building a core banking system in a distributed environment
Read this blog
Strengthening our commitment to cloud native design
Read this blog
Cloud Native - what does it mean? An interview with CNCF's Cheryl Hung
Read this blog
Shaping the future of banking IT: We’ve joined the Banking Industry Architecture Network (BIAN)
Read this blog
Why microservices are the future of banking
Read this blog
GFT and Thought Machine forge strategic partnership to accelerate global banking transformation programmes
Read this blog
Q&A with Nick Wilde, MD of Thought Machine Asia-Pacific
Read this blog
How Thought Machine can unlock the cloud for banks with Red Hat OpenShift
Read this blog
Round table: Meeting the challenge of a digital future
Read this blog
How to go full cloud native with CockroachDB
Read this blog
Meet our chair Andy Maguire
Read this blog
Core banking transformed: accelerating migrations with cloud-native cores
Read this blog
Let business justify your investments into digital-native core banking systems
Read this blog
How Thought Machine exceeds global industry standards in compliance and security
Read this blog
Thought Machine redefining banking with Standard Chartered
Read this blog
Sign up to our newsletter
Thank you! You will now receive some incredible content in your inbox!
Oops! Something went wrong while submitting the form.
For information about how we use your data please read our privacy policy.