November 20239 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. 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. TO FULFIL THE ENORMOUS BENEFITS OF A CLOUDIFICATION PROCESS, WE NEED TO BE READY TO ACCEPT WHAT IT MEANS TO BE CLOUD NATIVE
< Page 8 | Page 10 >