Allianz Indonesia

In the last few years, we have seen a push for cloudification of IT services in the financial industry. If you looked at the slide decks of all those Cloud providers, you’d notice that assured benefits of a cloudification investment can be summarized as higher operational resilience and great cost reductions. Talk to senior IT leaders in the APAC region about cloudification, and you, unsurprisingly, will recognize three lines of thought: enthusiasts, sceptics, and, finally, those that will share their distaste, convinced that this movement is a misstep.

This latter group would argue that there is a growing number of PRs from digital native companies announcing they are abandoning partially or completely the Cloud to invest in their data centers. Those communications often come with a thorough, well-documented case study on why running your data center makes sense on several dimensions.

Spend some time with any Cloud provider presales team, let them do a cloudification pre-study on your organization, and you’ll end up with many documents suggesting colossal cost savings. It is only natural that senior IT leaders used to be sold a new panacea every five years cycle, grow now suspicious about the benefits of these cloudification initiatives.

My colleagues and I believe that if we leave aside prejudices and look at the facts, we see evidence that the Cloud can potentially deliver immense benefits, including generous cost savings to a traditional financial services organization like ours. However, to attain most of those unrealized benefits, it is compulsory to adjust how the organization works, not just the IT part of the organization.

Moving to the Cloud doesn’t consist in matching the capabilities of the Cloud against our organization’s current way of working; what we’re looking for is something that will set up our organization to run in new divergent ways. For instance, present-day software delivery methods such as DevSecOps are supercharged in the Cloud; in the old-fashioned datacenter world, controls cripple proper DevSecOps practices due to the lack of transparency inherent to being on-premises; however, Cloud bears transparency, making those controls gratuitous. One more example: we must obtain cost savings by setting automation to spin up replicas of a system at will in virtually no time, eliminating the obligation for having redundant stand-by servers to increase system uptime, yet, Cloud transparency should be leveraged further with full gas automation: Infrastructure as code (IaC) and DevSecOps practices applied to IaC; gitOps beyond container orchestration, gitOps applied to legacy appliances, a radical break-up from current datacenter practices, endowing both Cloud promises of resilience and cost gains through finespun workload optimization.

"  To fulfil the enormous benefits of a cloudification process, we need to be ready to accept what it means to be Cloud native  "

Nowadays, IT drives the financial industry business, and it does it through rapid change. We want to keep delivering change at an ever-higher pace, we want to increase resilience, and we want to optimize costs. Do we want to spend months refactoring our applications to be Cloud native, pretending that we know what it means to us to be Cloud native, fooling ourselves on the idea that we know how we will operate in the Cloud, and worse than all, making business change wait until we are done refactoring? Or do we want to gain experience as soon as possible, make safe mistakes (the best way to learn), and grow our skills and capabilities, while we keep delivering change? Perhaps postulating this as a dichotomy is a fallacy, but once we asked ourselves the question in these binary terms, we had clear what principles were going to guide us in our cloudification journey.

If we have empowered software engineering teams, and we do, chances are they will start leveraging on the Cloud capabilities fast once both their development and production environments are in the Cloud. Here is where the rubber hits the road, where we start to see the friction amidst our compliance procedures and our automation, where the operations and development wall of confusion becomes evident as an obstacle to the organization’s progress. Even the antiquated financial and budgeting processes get their share of fret when pay-per-use and autoscaling workloads clash with locked budgets and a fictitious separation between run and change. We were not in a business that needed a change so that it ran. This shakes the organization in a good way, and it makes the inefficiencies evident; that’s when and where we need to succeed to attain all the promises: the benefits of the Cloud.

Then eventually, someday, we will have new operating models and cultures in place. It may make economic sense to start off-loading parts of our workloads to a data center because it will be then that we will run a data center differently with different processes, practices, mindsets, and priorities. And then, perhaps, it will make sense, as we are seeing with others recently.

To fulfil the enormous benefits of a cloudification process, we need to be ready to accept what it means to be Cloud native. Transforming existing organizational structures and processes to embrace the Cloud is challenging. We cannot buy our way there with money. A vendor can bring experience, brains, and hands to help, but we need to roll up our sleeves and be ready to be challenged at every level.