The financial services industry is slowly catching on to the many benefits of using the Cloud, well at least at a buzzword level.

The issue for many technical leaders and executives however in financial services is making sense of the variations in how technology is described when alongside the word Cloud.

Within Finextra alone, you can find articles that reference technology that is: ‘Cloud ready’, ‘compatible’, ‘native’ or businesses that are ‘born in the cloud.’ As an engineer or technical leader, describing what all this means to business executives can get tricky.

In this article I hope to provide some help to my technical peers in cutting through the noise using language (I hope) that helps get a wide range of people, with varying technical abilities, all on the same page.

IaaS and PaaS

We all need to start off with getting everyone on the same page, in terms of the difference between the main implementations within the Cloud.

Infrastructure-as-a-Service (IaaS), I often describe as equivalent to the hardware, as in, the PC you are using without any software on it, including the operating system. It’s the physical ‘tin’ or ‘kit’. Platform-as-a-Service (PaaS) I lazily explain as equivalent to the operating system on your PC, so Windows. In such a case, PaaS does a lot of the heavy lifting for you, just as Windows does on my PC. 

Azure / AWS / GCP

Azure is Microsoft’s Cloud offering, which is a little more PaaS focussed, and AWS is Amazon’s Cloud (Amazon Web Services), which is more IaaS focussed. Google’s offering is the Google Cloud Platform or GCP. These are the three major players but other brands of Cloud are also available.

Cloud compatible

Usually applied by a software vendor making a ‘Cloud saving’ statement. Meaning essentially, the software they have developed and sell, wasn’t designed with the Cloud in mind at all, rather it dates to the days of good old client server. However, if you want to run it in the Cloud, they believe it will (or should) run in the Cloud.

Now the key to remember here, and to ensure your executive understands is: this isn’t because the supplier has necessarily done anything to their software, rather they are taking advantage of Cloud IaaS capabilities to run their software. The vendor will have tested this, hence the confidence in being Cloud compatible. But check where they tested and how. Often it will be through the use of containers (Docker) within AWS. The salesman though may state no reason why the same couldn’t work with Azure, and in most cases that’s correct. However, support, maintenance etc are all areas that need to be covered off. Azure is just as complete as AWS for IaaS, but is the software vendor’s team that supports it also familiar with Azure?

Cloud compatible though doesn’t mean the software is taking full advantage of the benefits Cloud can give you, benefits that include elastic scale and cost reduction possibilities. It also doesn’t mean you will enjoy the massive uplifts in your resilience, availability or performance capabilities, which you should expect when being ‘in the cloud’.

Cloud ready

This again usually refers to what is essentially client server software that should work in the cloud using an IaaS implementation. The term ready has been used probably because what was desktop-based software is now accessible via a web browser. Thick applications moving to a thin client.

Cloud ready has all the same shortcomings that Cloud compatible has, ie it doesn’t take advantage of the full benefits of being in the cloud, that elastic scale, increased resilience etc.

Cloud native

Now this is the big one.

Cloud native means the software was designed and built using Cloud principles. The ethos is therefore to include high levels of availability, elastic scale capabilities and to meet user demands without traditional capacity planning exercises. Software that is Cloud native follows a modern architecture. Therefore, it should move forward with your business, in terms of scale, but also in terms of your ability to update it to meet new business requirements.

I speak a lot about Cloud native and ‘micro-service’ based architectures especially those that follow an event pattern implementation. However, when talking with the exec or at a bank board level, I try to focus in on just two phrases:

1. Elastic scale
2. Parallel running

Why do I single out two relatively basic statements?

The first statement, elastic scale, is to ensure an understanding that, the more customers that come onto the service the more demand they place on your systems. You need to increase your capacity to meet that demand, if not, your services become unavailable and your customers cannot make a payment, for example. So just like a piece of elastic, you want to ‘stretch’ your capabilities and capacity to meet demand, hence elastic scale. However, when your customers do not need that scale, just like elastic, you let go and it shrinks back down to the minimum size you require.

That scaling up costs you money, but that scaling down also saves you money. The key to remember is, that with a typical ‘on-premise’ solution (think of when each business needed a datacentre or server rooms), and even Cloud compatible / ready solutions, you typically have to set your capacity levels up front. That means you are almost always, at all times, paying for far more capacity than you need. Essentially Mr CFO: you’re wasting the bank’s money.

Parallel running is the second phrase I focus on as its an easier concept to grasp for non-technical people than ‘horizontal scale’ (which is exactly what I mean here). I have two very crude ways of describing parallel running (horizontal scale) to the exec.

The first, is that of an illustration of a tractor and the technology that goes into a tyre. I explain that you can keep pouring money, resources and technology into tractor tyres to ensure they don’t fall flat, however, at some point you have to simply admit that one will fall flat. So, to combat against this, instead of having just one tyre per wheel, you have multiple wheels across the four corners of the tractor with multiple tyres, so when one goes flat, you simply don’t notice – there is zero interruption to your service. I use this analogy to explain why running multiple instances of the same services provides you with greater levels of resilience, something you can only do if you follow a micro-service type of architecture and realistically, you are cloud native.

The second crude example I give of parallel running (horizontal scale) is that of handling transactions per second. If one service can complete a transaction in one second (as in a payment) then that is its capability. I can invest time, effort and money into getting it faster and faster, or, I can opt to run multiple instances of the same service. If 1 instance can complete 1 transaction per second, then a second instance can also complete one transaction per second. In total, my system is now performing at 2 transactions per second. If we want to achieve 10 transactions per second, I simply run 10 instances of the same service, all executing in parallel.

In a presentation to the entire bank, I once illustrated this with pushing ten staff members across the floor in their office chairs. I took this further by initiating a race between two teams. One team had just 1 ‘pusher’, who had to push 5 colleagues to the other side of the office. The second team consisted of 5 members, who also between them had to push 5 colleagues to the other side of the office. Clearly, the team with 5 pushed all of their colleague across the office in roughly the same time it took team one, to move just a single colleague.

Born in the cloud

This can be a very ambiguous statement given that you can run all three of the systems discussed above in the cloud, and therefore launch your business from a Cloud based infrastructure. I personally don’t feel you should be able to lay claim to being ‘born in the cloud’ unless the vast majority of your systems are cloud native, but that may be me being too much of an idealist here.

There are many financial service-based organisations that lay claim to being ‘born in the cloud’. For me, and what is key to get across to any exec (or buyer), is the question of which of those systems are NOT cloud native. If you have a dependency on a number of systems that are simply Cloud compatible, then I think it can be a bit misleading using the word ‘born’ to describe the whole enterprise, as certain key technologies were clearly born well before Cloud.

In conclusion

Cloud is becoming a hot topic beyond the IT department; financial service executives and board members are becoming increasingly aware that Cloud is a good thing – and therefore software vendors and companies are maximising their ‘Cloud’ credentials. It’s key for technical leaders within financial institutions to get under the bonnet of these claims and translate them into language, illustrations, presentations that all the executive and board will understand.

As technical leaders, we must remember that the technology world is full of language and terms that can quite frankly be very confusing. It is therefore our duty to translate the technology, and the marketing claims, back into plain language – so that we can make correctly informed decisions for our organisations.