David Bejar, Head Of Software Engineering, Allianz Indonesia
In the last few years, we have seen a push for cloudification of the IT services in the financial industry. If you had a look at the slide decks of all those Cloud providers, you’d noticed 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 later 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 own datacenters, those communications often come with a thorough well documented case study on why running your own datacenter makes outright 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 a bunch of documents suggesting colossal cost savings. It is only natural that senior IT leaders used to being sold a new panacea every five years cycle, grow now suspicious about the benefits of these cloudification initiatives.
What me and my colleagues believe is that if we leave aside prejudices and just 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 the way the organization works, and 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 proper DevSecOps practices are crippled by controls 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 stand-by redundant 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.
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 (best way to learn), grow the 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 for 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. Like though we were not in a business that needs change so that it runs. This shakes the organization in a good way, it make 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 culture in place, then it may make economic sense to start off-loading parts of our workloads to a datacenter, because it will be then that we will run a datacenter differently with different processes, practices, mindset, and priorities. And then, perhaps, it will make sense, as we are seeing with others recently.
To fulfill 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 obviously challenging, we cannot buy our way there with money. A vendor can bring along experience, and brains and hands to help, but we need to roll up our sleeves and be ready to be challenged at every level
Weekly Brief
Read Also
