What happens when finops finds bad cloud architecture?

Cloud finops, a practice that combines financial management and cloud operations, is instrumental in optimizing cloud costs and ensuring efficient resource utilization. It is one of the most important emerging trends in cloud computing, and I’ve covered it a great deal on this blog.

Its benefits extend beyond cost control. Let’s explore how cloud finops can also help highlight poor cloud architecture practices that lead to bad deployments. By analyzing cloud cost data and patterns, finops teams can identify areas of concern and what needs to be fixed. Will we be able to leverage this for the good of cloud deployments? We have a few things to consider.

Cost analysis and optimization

Cloud finops teams have access to detailed cloud cost data. This enables them to analyze spending patterns and identify poor cloud architecture practices that contribute to unnecessary underoptimization and waste money.

Mistakes include overprovisioning resources, lack of automation, inefficient containerization, or improper utilization of reserved instances. In many cases, bad decisions were made in the past and will take many years to fix; in fact, they may already have done irreparable damage to the business.

Finops observability systems can analyze cost data and pinpoint specific resources or services driving up costs. This usually leads to potential architectural improvements and significant cost savings.

Performance and scalability evaluation

Cloud finops teams can evaluate the performance and scalability of cloud infrastructure. Monitoring key performance indicators such as response times, latency, and throughput can identify bottlenecks or areas where the current architecture limits scalability and performance.

Since finops normally tracks this through money spent, it’s easy to determine exactly how much architecture blunders are costing the company. It’s not unusual to find that a cloud-deployed system costs 10 times more money per month than it should. Those numbers are jarring for most businesses. Remember, all that money could have been spent in other places, such as on innovations.

Some finops systems can calculate the net losses of these architectural mistakes. In many cases, you can even see the net drawdown on business value.

An example: using only a single public cloud provider without considering others that may have better solutions, such as a database that can perform five times faster, providing better performance and savings for the 50 or so applications that use it. The better database would have been one-third the cost, provided five times the performance, and saved $15 million a year in productivity gains. It gets worse. That $15 million could have been used to develop a new product line, which the company could have turned into $100 million in revenue. This may seem like an extreme example, but I’ve seen things like this come to light after some analysis of cloud architecture, missed opportunities, inefficiencies, etc. It’s more common than many realize.

Damage control

Okay, now the question that most cloud pros don’t want to deal with: What if your cloud architecture has some major inefficiencies?

I suspect most cloud deployments have some degree of inefficiency, so you’re not alone. It’s good to come to terms with the damage so money can be allocated to fix the issues. I suggest breaking each issue down into domains that can be addressed separately and handling them in priority order, from the most expensive to the least. You’ll need to fight many battles to win the war.

Most of these will be things like poorly designed databases, the wrong technology, poor cloud deployment, and cloud operations planning—things that are tactical in nature, and, although not easy to actually fix, are easy to understand how to fix.

However, there are more strategic blunders, such as only using a single cloud provider (see example above). Maybe it seemed like a good idea at the time. Perhaps a vendor had a relationship with several board members, or there were political reasons for the limited choices. Unfortunately, the company still ends up with a great deal of technical debt which could have been avoided.

Keep in mind that finops is not perfect. It’s good at finding areas for better optimizations, but tracing that back to poor architecture practices still needs to be sussed out by good cloud architects. In other words, finops is good at spotting problems but does not yet pinpoint the issues or how to fix them.