For years I’ve ranted about the lack of fiscal responsibility around how we pick and leverage cloud technology for enterprise deployments. There are dozens of solutions that solve the same problems using cloud resources, but only one can fully optimize a specific business case and the business value it should return.
It’s time to admit that at the beginning of our cloud deployments, our teams weren’t as skilled or knowledgeable about how to best address our enterprise’s specific problems. Perhaps our cloud architects now realize they could have made better choices when they picked and configured the technology stack. Hindsight is 20/20, right? However, when questioned, their natural inclination is to get defensive. They usually push back on any criticism, constructive or otherwise, with some version of, “It works, doesn’t it?”
How do we get past the denials to fix the optimization problems? It helps to first understand how they came about and the obstacles to finding solutions. Those charged with making the final calls on cloud computing architecture decisions are often C-level tech executives who are difficult to question. Perhaps the decisions were made by teams of people who clearly suffer from groupthink and continue to go along with bad calls. Or a committee, which is even more difficult to question. No one wants to admit when they’re wrong. In many cases, office politics or the questioner’s lack of technical cloud knowledge makes it easy for decision-making groups to deflect and deny.
Sound familiar? In most enterprises, poor cloud computing architecture is often overlooked or ignored, from the small to the large. This results in an underoptimized cloud architecture that can cost the business millions a year and remove much of the business value that its cloud solutions could bring. Some enterprises are now beginning to realize that you can kick this can only so far down the road.
The solution? The concept of cloud finops emerged in the past few years to help deal with optimization problems, which I have also worked with and written about. The core goal of finops is to monitor cloud spending and usage, determine key insights, and optimize spending and operations so the maximum value is returned to the business. The key word here is “optimize.”
As enterprises realize that the business value promised by cloud computing is still not there, most will (either soon or eventually) determine the root cause to be the lack of optimization. Finops can identify the usual suspects to do some course corrections. It can perform overall evaluations of what cloud technology is used, how it’s used, and for what purpose. Based on those factors, finops can leverage reserved instances, kill zombie cloud services that were not shut down, and employ other tactical solutions to save cloud usage money. However, tactical solutions are not where the big amounts of optimization money get left on the table.
My assertion is that it should be a natural progression of a finops program to review the core cloud solution architectures. Hear me out. After finops does its overall evaluations, it’s time to dig deeper. Finops can help you identify the number and types of technologies in the mix and justify each one to help pinpoint where the technology needs to be reconfigured to result in a solution that’s as close as possible to being fully optimized. That is how you return the maximum amount of value to the business.
Examples of potential finops recommendations:
- Use a single security layer that spans all clouds rather than separate security for each cloud brand. This will save many operational dollars, as well as reduce the number of required staff skills.
- Combine databases to simplify a database deployment into a single database model to reduce complexity and minimize additional skills that may be required.
- Provide performance management systems that offer better load balancing, which can reduce the number of allocated compute services.
- Leverage AIops for cross-cloud operations.
- Use automation to remove the number of humans required to actively monitor the cloud-based systems.
Properly implemented finops is good. It’s no surprise that trouble lies in how it’s executed. The finops group needs the expertise to do such an evaluation, much like a cloud architecture audit. Most enterprises won’t have that kind of skill set in-house. Unless they can splurge on high-end talent, an unskilled audit could make things worse if the recommendation for cloud architecture changes just complicates the existing state of things. Splurging on a consultant or in-house talent would cost some money, but hiring the right skills for the project should return 100 times the amount invested.
Assuming that politics will always be an issue, it’s still a step in the right direction to provide this kind of formal, interorganizational peer review for cloud solutions that are in planning, as well as those that are already deployed. The greatest challenge will be cloud solutions that are in production but need to be fixed. Someone will have to admit they made some bad calls and then help take the risky steps to fix deployed systems.
Of course, there’s always the choice to do nothing, which I suspect is the current default mode for many who oversee cloud architecture disasters. It’s easier to go along to get along. However, a properly implemented cloud finops program that digs deep into cloud solutions will eventually call everyone’s decisions into question, even our own. This will require justification far beyond “it works” and the ability to admit when or where we made mistakes. It’s just the right thing to do.
Copyright © 2022 IDG Communications, Inc.
