FinOps Pain Points we address
Empowering engineers to take action
What prevents action is likely to depend on the nature of action needed and will vary from one organization/engineering team to the next but we empower engineers to act by:
- saving time so they can focus on areas that make the best use of their expertise, interest and authority to act
- saving money that can fund testing and new initiatives and demonstrate good financial control to help future cloud budget approvals
- building flexibility to ensure that cost savings do not come at the expense of being able to change their use of the cloud.
Expertise and interest
Engineer expertise and interest is in cloud technology, not cloud pricing. We enable cloud usage optimization to be separated from cloud rate optimization to give engineers freedom and time to take technical action that makes full use of their expertise and interest.
With so many cloud services available, all of which can be switched on and off very dynamically, often through code written by engineers, it’s natural to turn to engineering teams for any question about your cloud bill. The urge to do that is one you should avoid if you want to avoid distracting them from doing what they do best.
They know, and need to keep up, with the ever-changing technical landscape and what functionality, security, availability and performance your organization needs now and in the future. This is enough of a challenge so let them stay focused on it.
Lack of authority
Savings Plans and Reserved Instances represent a financial commitment and engineers are rarely authorized to act entirely independently in making them. This creates barriers to taking such “rate optimization” actions and also limits the extent automation is allowed (State of FinOps by FinOps Foundation). We remove these barriers and the responsibility to manage commitments, to release time, which empowers engineers to take action in other areas.
Even if engineers have the authority to act without these controls, and no matter how clear the potential benefits are, the personal risk of making expensive mistakes can create a hesitation to act. This may result in more time spent analyzing and forecasting to increase confidence, more conservative actions that fail to access the best discounts or a failure to take any action. None of this is empowering engineers and certainly not in a way that makes the best use of their expertise and interest.
Access to Budget
Testing and exploring new initiatives will likely require cloud resources and hence money to pay for those resources. Without the approval to spend that money, engineers are not empowered to act.
By making savings on existing cloud spend we release money to be used elsewhere and demonstrate good cloud financial management which often makes obtaining approval for future funding easier.
Enabling technical freedom
While AWS Savings Plans and Reserved Instance commitments can provide big savings, overly simplistic, poorly considered use can produce lock-in to particular spending levels or use of specific resources. This can limit choices or negate the benefits of re-architecting, rightsizing or migrating as organizations may end up paying their committed spend level or paying for both the old and new resources.
By removing, or at least minimizing, this lock-in we empower engineers to use the resources they need, no matter how those needs change.