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.
