By Pini Reznik, chief revenue officer and co-founder of Container Solutions 

No matter what industry your business is in, you are most likely facing market pressure from successful newcomers – think here the likes of Uber or AirBnB. This is particularly the case in the finance sector, with the Covid-19 pandemic creating an almost overnight shift in how businesses and consumers move money. The catalyst may not be there yet, but there is a very high probability that it is coming in the foreseeable. 

The main reason why these disruptive strangers are able to establish themselves so quickly and threaten the status quo is their ability to operate faster and more effectively using modern technologies. They have a rapid cycle of developing a product, presenting it to the market, getting immediate customer feedback and, based on that feedback, delivering even more feature innovations and improvements. 

Some of these high-performing capabilities are definitely a good start. Cloud native, however, takes things to the next level by taking full advantage of cloud computing. If you’re a traditional financial company, where it’s pretty much impossible to incorporate user feedback in a useful timeframe, and a new, web-based competitor like Starling using cloud native technology advantages comes into your sector, that competitor’s growth is not going to be a nice, straight line. It’s going to be a steep exponential curve. 

But what exactly is cloud native?
Though the terms are oftentimes confused, cloud computing and cloud native are two entirely separate entities. Cloud computing, for one, is the on-demand delivery of infrastructure, storage, databases, and all kinds of application services via the internet. Usually, these are provided by a cloud services platform like Amazon Web Services (AWS), Google Cloud, or Microsoft Azure.

Cloud native, on the other hand, is a philosophical approach for building applications that take full advantage of cloud computing; an organizational destination for enterprises looking to modernize their infrastructure, process, and organizational culture, carefully choosing the cloud technologies that best fit their specific case. 

This new paradigm requires not only embracing new technology, but also a new way of working – which makes going cloud native an extensive undertaking. Identifying, provisioning, and then deploying the right combination of services to best take advantage of this new, rapidly evolving world among the clouds can take very different forms, depending on the needs of a particular organization. As a result, it’s easy to get it wrong. Below, I list the three main reasons behind it.

Difficulties due to the complexity of distributed systems
We now live in a highly mobile world, where apps get accessed and used across a plethora of platforms and devices. Users, in turn, expect a fast, seamless, and always-on experience. To fulfill these expectations, companies have adopted distributed systems to manage the inevitable fluctuations and failures of the complex, behind-the-scenes services required to run it all. In fact, many of cloud native’s superpowers are granted by the sheer merit of its distributed-systems architecture. But when distributed systems become complex, then design, construction, and debugging all get much, much harder. Failure is pretty much inevitable, and engineering teams need to accept that and come up with contingency plans, so that the end users hardly notice when it does happen. 

As you can imagine, peering inside a distributed systems technology stack to understand those failures is an enormous challenge, and so sophisticated observability is essential. The tools and knowledge necessary for detecting those failure points are extremely advanced, and few companies have the ability to do this for themselves.

The relative immaturity of the cloud native ecosystem
Because cloud native is still so new, the current landscape of cloud technologies and vendor offerings is constantly evolving. And whilst public cloud platforms are usually presented as full end-to-end solutions, in reality they are far from plug and play; half of the necessary stuff is missing. 

Usually, companies used to full mature tech solutions like virtual machines are unpleasantly surprised to find that configuration is manual, and not all the necessary pieces are even present. But since they have believed their cloud vendor that their platform was a full solution, they haven’t allocated people or budget or time to build or buy the missing or incomplete pieces.

The failure to adapt and evolve organizational culture
In order to make a successful, effective, and above all worthwhile migration to the cloud, the entire organization – not just the tech stack – must change. This means evolving non-technical aspects such as management practices, organizational structure, and team responsibilities to work in your new cloud native context.

Otherwise, if you simply layer the latest tech on top of the same old way you have always done things, you will create a whole new slew of problems, including slow delivery, reduced quality, and difficulties in both project and team management, which is the opposite of most cloud native transformation goals.

Your organization’s culture needs to change along with the technology. If it doesn’t, you are very likely to waste a lot of time and money on an ultimately unproductive transformation.

What it looks like when cloud native transformation goes right
When the entire company has gradually evolved to be working in the cloud native way, build-run teams are able to rapidly develop new features and deliver quick, incremental improvements. CEOs and executive teams will have embraced a dynamic strategy and throughout the entire organization there will be a focus on delivery, but also continued and meaningful investment in ongoing innovation. The benefits are endless. But perhaps the main advantage is, you can now vary your company’s products or services in a cloud native pipeline with the same ease and speed you might update your website using a content management system. 

Let’s take a look at Starling Bank, for instance. It’s no secret that, traditionally, banking companies deliver software very badly. The main problem is the business/IT distinction: typically, you’ll get business people writing specs; these get thrown over the wall to IT, who tries to translate them and deliver, and then throws it back over the wall to business, who will do some sort of acceptance testing, find they didn’t get what they want, have a bit of a moan, and the whole cycle goes round again.

Starling Bank was born in 2016 to change this paradigm. In order to do so, they realised they had to think of themselves as a tech company with a banking license, not a bank that needs to try to do technology – it became the first UK current account available to the general public to be deployed entirely in the cloud, including all of their processing, balances, accounts, services, and APIs.

They believed that by using Infrastructure-as-a-Service, DevOps, and continuous delivery, they would organically grow an innovation culture in their teams. But perhaps the main benefit they found from going cloud native was the ability to experiment. If you’re in a cloud environment and want to try something out with a hundred servers, you try it out for an hour, and if it doesn’t work, you stop. No costs attached. You can’t do that sort of thing with on-prem infrastructure.

And, as a result, they have been able to move fast enough to deliver plenty of UK banking firsts: first to deliver in-app provisioning of both Google Pay and Apple Pay. First current account available to the UK public entirely on the cloud. And so on.

Going Cloud Native
The point of moving cloud native is not the speed itself, but your ability to move at that speed. Cloud native is about building an organization that can transform and adapt far faster by removing the technical risks associated with change. It is as much about de-risking as it is about accelerating change, allowing companies to become more responsive. It’s extremely powerful, yes—but unfortunately “low risk” does not mean “low effort.” The transformation process isn’t free, and it isn’t easy. But what I can tell you is that it’s imperative, in an existential threat sort of way, and absolutely worth it.

About Author: