Why FinOps Should Expand out of Public Cloud
FinOps goal is not simply lowering cloud cost, the focus is to bring financial accountability to variable cloud spend within an organization. Many companies today realize both in Finance and Dev/IT that cloud can be unpredictable as they scale to support the growth of their business. FinOps in 2021 is still in the crawl or “conception” phase for many companies as they grapple with the ROI of dedicating these teams to their business process & culture. However, many organizations need to consider the expansive functionality and investment reach “cloud” has become as it is not just IaaS. Voice communications network connectivity are both new areas where financial Opex in a FinOps model should exist.
FinOps for UCaaS & CCaaS
The compounded annual growth rate for traditional voice and call center shift to Unified Communications as a Service (UCaaS) and Contact Center as a Service (CCaaS) has grown substantially. UCaaS for most providers should be a flat, fixed rate on core voice communications of local, long distance etc. UCaaS licensing does offer additional integrations into Microsoft Teams, SalesForce, HubSpot, Bullhorn, Slack and many other SaaS tools for a flat licensing cost. This is great for Finance teams who are accustomed to traditional licensing costs even back to the advent of commercial datacenters. However, many organizations fail to do the following within a cost-aware culture.
- Immediate turn-down of UCaaS seats upon termination or role change of an employee
- Audit Suite or Office 365 licenses to the UCaaS integration – many IT teams forget to cancel the integration license, overpaying for services.
- Issue physical phones when a soft phone with training can adequately suffice.
- Add additional Dialing Plans to Teams when the UCaaS option exits and typically less costly.
FinOps for SDWAN
As more companies shift off predictable MPLS network cost models to sometimes unpredictable software defined WANs, both IT and Finance have an option to work together here. Sure, network based SDWAN generally should not fluctuate once implemented as costs are fixed. However, a few areas not easily baked into the solution can cause cloud WAN costs to rise.
- Burstable Internet circuits:Often, Network teams will opt for a lower cost internet circuit which is burstable to a higher speed. Examples include
- 20M burstable to 100M
- 100M burstable to 1G
- 1G burstable to 10G
What is great about this flexible access model is if for a short period of the day or month you require a large capacity circuit, you can by bursting to the total port size setup by the carrier. This model is described as the 95th Percentile Billing. However, many organizations do not truly understand this model and find themselves on the wrong side of a large carrier bill each month without predictability. Working with Dev and Finance teams a good FinOps approach is to build an easy model to apply the Opex in a flexible investment model. We work with countless companies to maximize this additional bandwidth in a cloud SDWAN model by bursting just below the 95th percentile peak. Using scripts or other tools, clients can in theory move their backups or other large transfers off-hours using a burstable capacity but build a ceiling to avoid overage charges.
- Long-term SDWAN Contracts– Post Covid, countless organizations have decided to go all in on public cloud, shifting resources off their campus data enter to AWS, GCP, Azure, Oracle etc. Making sound business decisions that create value should look deeper into the SDWAN terms. Do you really want to sign a 36–60-month agreement with low flexibility on a design that might not be required? If you are paying $100-200 per SDWAN node and something much less for remote users, is that a sound option knowing your cloud architecture will be the true end point? Zero Trust connection options might make more sense, reduce Opex not just by the monthly invoice but the less security feature set in a box vs. an agentless environment?