Strangling the big ball of mud
For many large financial institutions, cloud is, increasingly, the answer. Not that they’re necessarily sure what the question is, but the answer is definitely cloud.
For a long time, the answer wasn't cloud. The idea was anathema. Cloud isn’t secure, cloud isn’t safe. Cloud is risky, and we can’t be giving our data to another company to look after, can we?
But the pendulum is swinging. Challengers like Monzo and Starling are showing that you can safely and securely run a bank on cloud and run it better than the traditional players.
So eventually the edict comes down from on high, from the C-suite, cascading down through eight layers of management: move everything to ‘The Cloud’. Cloud is cheaper, more reliable, that company over there is doing cloud and they’re successful. Ergo, we will ‘do’ cloud, and we will be successful.
But Monzo and Starling aren’t successful just because they’re on cloud - they’re successful because they provide a fantastic customer experience. Architecting for cloud is part of the reason they can do this, but it’s not the only reason and it’s not the primary driver. It’s simply the best way to meet their customers’ needs.
On cloud, you pay-as-you-go and you only pay for what you use.
To be fair to the big institutions, there are people within them that know how to do this and what needs to be done. But they’re trying to enact fundamental change when many parts of their vast organisation view cloud as an existential threat. If you’ve built your career on running data centres, you have to be very open-minded to consider cloud (a turkey is unlikely to vote for Christmas if it can’t see a role for itself beyond ‘main course’). The corporate antibodies will swarm.
Adoption is a balancing act
So how do you do this? How do you ‘adopt The Cloud’, and how do you do it quickly? Well, many think ‘lift and shift’ is the answer, pick up your apps and plonk them on cloud. Any of the major cloud providers will do you some virtual instances that look a bit like traditional servers. And then the magic will happen.
Only it won’t. For starters, it’ll cost you more. On a like-for-like basis, cloud is expensive. But then, per hour, a hire car is more expensive than the car you own. And that’s the point. If you only needed a car for an hour, just hire it for an hour and if you don’t need a big car, swap it for a smaller one. On cloud, you pay-as-you-go and you only pay for what you use. So you can optimise your architecture, you can tune your system to turn itself off when not in use and save money.
Incidentally, don’t try to build your own. Amazon, Microsoft and Google do this really well. Most of our traditional financial enterprises, not so much. And even if you do it well and you can scale up and down, it’s still in your data centre and you’re still paying for it all of the time.
Enter the Chaos Monkey
Cloud can be unreliable. This scares big banks, but they tend to miss the fact that most of their own internal systems are unpredictably unreliable. Public cloud is unreliable, but within known limits and published Service Level Agreements (SLAs).
You can (and should!) design your applications to cope with this. You should build them, to mention another fashionable term, antifragile. Netflix built a ‘Chaos Monkey’ to do just this, to purposely disrupt their platform to ensure that it could cope and recover.
This mindset and approach to total transparency is why challenger banks can inform customers there may be an issue even if the customer never actually encounters it. Contrast this with the major outages of high-street banks where outraged customers have had to get most of their information from Twitter or the media.
Of the many reservations incumbents have about cloud, by far the biggest is security. The thought of giving precious customer data to another company to look after is one that keeps executives awake at night. And yes, there are different threat vectors, and a distributed cloud-based architecture will likely have a greater attack surface - all things that weren’t a concern for a legacy system that was designed decades ago.
There’s a level of assumed security in a data centre by virtue of the fact that it’s in a building with walls and doors with locks, but things are a little ‘softer’ once you get inside.
In contrast, an application built for cloud should be designed with ‘defence in depth’, taking advantage of full logging, alerting and audit capabilities for threat detection and data encryption. Not only secure, but demonstrably secure.
Step away from the big ball of mud
Public cloud has lots of benefits, and some known challenges which you can mitigate if you design your system from the ground up to take advantage, to be ‘cloud native’. Your average big-ball-of-mud banking system wasn’t really built with cloud in mind, it’s a crumbling monolithic structure that can’t be moved to the cloud as is. You need to start again and do it differently.
At 11:FS, we’re digital first, and that means cloud first. When architecting digitally native services, we start small and move fast, building loosely-coupled containerised microservices that each do one thing and do it well.
Our services are stateless so they can scale out and in with ease (more instances when needed, then fewer when demand subsides). They’re also event-driven, so there are fewer bottlenecks and we have a complete record of everything that’s ever happened to the system.
We take full advantage of public cloud, but can deploy to a datacenter if client needs dictate.
So, if you have a mandate to move your legacy application to cloud, think seriously about starting again, or at least about redesigning bits of your system and moving it bit by bit and maybe strangle it. Because the only way you’ll benefit from moving your monolith to cloud is that management will soon start shouting about how expensive it is to run. Then, with no way back to the datacenter, you’ll have to redesign it.
We’re here to help build up your tech teams and offerings. Get in touch with one of our experts.