Aside from building the project at hand, our biggest job as systems integrators is guiding clients through both the technical and financial decision-making process. In some ways, the technical process is easier. Most systems contracting professionals are adept at analyzing technical choices, weighing the pros and cons of different equipment vendors and transmission protocols in an on-prem scenario. But that all changes when you move to a hybrid environment, as do the financial implications.
Decisions must be made around what technology would benefit from virtualization versus when it won’t provide gain and could possibly be a negative. As discussed in detail in my last column, a situation where any cloud-induced latency can’t be tolerated often leads to the creation of a hybrid system.
Think of IFB as an example where we must keep certain signal paths on the same location as the origination point to minimize latency for talent monitoring. When factors like latency are critical to the working environment, performance becomes a determining factor that overrides cost projections.
The OpEx Transition
Once an integrator has determined the optimal design, the next step is demonstrating financial benefits to the client. And this is as complicated, if not more so, as putting the technical system together. That’s because most systems contractors are used to planning with a CapEx approach that’s prevalent today. The transition to a hybrid or fully OpEx model is not only difficult for the system contractor but also for the client trying to make the right choice.
Developing your cost models enables not only solid technical decisions but also sound financial decisions.
Systems contractors have typically considered on-premise costs and the client’s amortization schedule first. That determines the cost spread over a fixed period. We focus on the total cost of operation (TCO), which involves the cost of acquisition, installation, and maintenance, spreading that out across the time the technology will function. Those numbers are run against a depreciation schedule. That's math we’ve all done thousands of times for our clients.
Imagine instead of these CapEx spends, every piece of equipment in the system is rented from a vendor. We now must analyze how long it will last and how much it will be used. You also may need to include technical support for the entire time you're renting it. Perhaps the maintenance contract is built into the rental.
[Cloud Power: Decisions, Decisions]
Another variable is the cost of renting the platform the software runs on, such as Amazon or Google. This math must be added to what is already a complex financial calculation. Then, these costs are compared against the cost of purchasing and maintaining it outright.
When equipment is purchased for on premise, the cost never changes, no matter the usage. Whether it’s used for 10 events or 100, the cost remains the same. If I'm “renting” it from a vendor based on time used, the cost calculations involve how long I’m making this system available—12, 24, 36, maybe even up to 60 months. Plus, how often is it turned on? In public cloud, this is all based on a by-the-minute “consumption” model. This is the critical stuff clients need to know before making decisions.
Technical Advantages
In some cases, there may be technical advantages that will drive the decision. For example, the client may want a specific set of operators to run multiple shows worldwide. In that case, a cloud-based system is obvious since the operator location is irrelevant.
With a hybrid workforce, this could influence decision making. You will need to roll in the maintenance cost of on-prem versions versus the in-cloud versions. All this winds up on a spreadsheet with some amortization schedule.
[Viewpoint: Here Comes Convergence]
While on-premise costs are mainly fixed, some costs can vary. With a new building that has zero infrastructure built out, the math can change. Do I need to build a server room? If I’m building one, what’s the optimal size that allows for a smaller on-prem bill? Power and air conditioning costs must be factored in. If a building already has a server room in place, power and air conditioning are established, fixed costs. Moving to the cloud won’t save money because the physical support infrastructure is already there.
For hybrid or cloud-based models, many of our larger clients will have a contract with one of the hyperscalers that they will want tied into the financial equation. With a virtualized system, you have to make your best educated guess around utilization.
Does this need to be turned on 24/7 or just for specific events? Even when turned off, there’s a cost to living in cloud, because it occupies storage space. Figure out all the resources you would use, the virtual machine configurations, ingress and egress charges, signal transport charges, and build a cost model from there.
All About the Models
The cost modeling can be complicated when compared against our tried-and-true, on-premise CapEx model. But if you’re looking for the best possible outcome for your customer, all these things must go into your plan. This complex modeling is why many integrators are reluctant to make these cost comparisons.
[On Your Business: Why Small Businesses Need a Leadership Team]
Developing your cost models enables not only solid technical decisions but also sound financial decisions. It can be one of the most important competitive tools you have as a systems integrator today.
Conceptually, it's the same skillset that every salesperson or technical account manager has today. While these are significantly different models than many are used to working with, the concepts of cost comparison and cost benefits remain the same.
Experience is what will enable you to compare costs in the end. You must learn how to research and judge the costs of these variable parameters with each vendor and multiply those costs across the different hyperscalers.
If you really want to take it to its maximum benefit for the client, you must also consider the performance of the hyperscalers. Many of these infrastructures will run differently on the various platforms. Each of them has a different technical infrastructure, a different way of deploying products in their infrastructure, and varying methods of billing.
As an example, depending upon the complexity of the products we’re deploying in it, Grass Valley’s cloud production control room environment is often less expensive to operate in Google than it is in Amazon—sometimes by as much as 25-30%. That’s because of the way Google has configured the flexibility of its virtualized compute infrastructure. In some ways, AWS is faster to deploy because there are more set choices, but there’s less ability to customize it exactly for the performance required.
Looking Ahead
Where will all these choices lead us? I believe there will emerge a large, software-defined infrastructure market, which is public cloud based today but will focus on virtualized infrastructure on premise. This would be a different kind of hybrid scenario that features software-defined models driven by the public cloud methodologies, but where the client owns the physical infrastructure and virtualizes the applications.
The approach gives them the ability to be more flexible in terms of product and service offerings to clients, while having higher but more predictable costs than public cloud. This is software-defined infrastructure on premise. For example, if the TD at a facility where I placed a particular switcher prefers another, a different app and new configurations would be all that’s required to change it out.
[Blueprint for Success: Dance in the Rain]
There are so many hybrid ways to think about this. Google and Amazon, for example, have services where you can build their infrastructure on premise and run it like an open source microservices container-based environment—with hardware you’re renting from them.
With so many different approaches now, it can be daunting for an integrator. The choices are almost exponential in terms of their potential variations. That flexibility and ability to own what we do for our clients is a benefit. The trick is not to get bogged down in the myriad of options, but view them as increasing your expertise and value to clients.
