With large numbers of viewers streaming video, you want to ensure that your streaming services can handle the amount of traffic that gets thrown at it at any given moment. This means that infrastructure has to be bought in a size that has the power to service the number of viewers you have. However, when buying a fixed infrastructure, it fails to recognise and adjust to the differing numbers of viewers that appear at different times and dates. And this can quickly become expensive. You don't want to risk having a family car if you need to go at Formula 1 speeds, neither do you want to pay for a racing car, when all you really need is a family car.
But, there is a solution to this problem. And it's called auto-scaling.
Auto-scaling means that you only pay for the infrastructure you need at any one time. It means that as demand grows, more oomph is added to your infrastructure continuously so that you always have just a little more power and speed than you are using. And when the traffic falls away, so does the extra oomph. And you are no longer paying for power you don't need.
In the world of OTT, if your infrastructure is not powerful enough, your car won´t go fast enough, and you will not be able to stream content to audiences at the speed that is necessary. Viewers will not be able to view, watchers will not be able to watch. Screens will go dark, and those who tuned in, will turn off.
This is far from an acceptable situation for an always-on, TV anytime, TV anyplace, TV anywhen, TV anywhere channel or VOD service. In fact, it is the worst possible situation to face.
And there has always been a solution for this problem. Buy a fast enough car. Buy big enough, powerful enough infrastructure. Get your chequebook out and start writing, writing, writing.
And this seems simple enough. But the problem is that you pay for a race car, but most of the time you only want to pop to the nearby shops. You don´t need Formula 1 speeds for that, and you couldn´t reach 180 miles an hour even if you wanted to.
In the OTT world, the number of active viewers you have watching, drawing down content, demanding video served by that incredibly powerful engine, varies greatly. For instance, the volume of content being watched at 3 am on a Monday morning, is enormously different from the massive amount of watchers that will all turn on, at roughly the same time, in the five minutes before a World Cup Final on a saturday afternoon.
This means that your enormously powerful (and did I mention, tremendously expensive?) infrastructure is idling at the traffic lights for most of the day/week/month, with only an occasional top-speed corner or sprint-to-the-finish that makes the most of your high-speed engine and grippy tyres.
If you streaming services does not scale you run the risk of black screens, jumpy picture rather than a smooth stream, a gut-wrenching decline in quality of bit-rate due to the pressure of network traffic creating the worst experiences for viewers.
This risk means that the way infrastructure has traditionally been provisioned, is by selecting an engine that is powerful enough to service your peak times of demand. A race car for rare track occasions, when the reality is that you will be pootling around the local town most of the time.
And what constitutes a peak event? Exactly that, a World Cup final, the last race of the season, election night. Exactly the type of event, that if it goes wrong, will alienate the most possible viewers in one go.
And it gets worse. Because we never expect the unexpected. We cannot predict when the next world-changing event will happen in advance. Whether it is the Berlin wall coming down, the start of military confrontations or even war between some of the world´s super powers, or even yet another and even bigger outrage or disgrace than was thought ever possible, caused by the British Prime Minister.
And so we are paranoid. We live in fear of the black screens. What if this is the event that sees even more people want to watch it than any other event we have ever had?
So we add a safety margin. And rightly, because we don´t want to lose viewers. We want to be able to service the needs of all the viewers that might show up with their remote controls, their urgency, their impatience and their judgyness …
So we imagine what the peak volume of watchers would look like, and we don´t want to get caught out. Because that would be the end of my job. So, we get out our cheque books, and we sign to add a 20% safety margin by buying even bigger infrastructure, just to be on the safe side.
So now you have a car, with a special-supersonic-nitro-power that is much faster than you will ever need, faster than the racetrack will allow. And you mostly only need to pop to the shops…
(It´s a good job you have a fat wallet!)
Another alternative is to buy Infrastructure for your regular run rate, and have your engineers scale it up before a major event, then scale it down again afterwards. This comes with additional risk and additional management overheads. It doesn´t make practical sense to put a smaller engine in your car in between races.
This is where auto-scaling comes in, and why auto-scaling can help you business save money. Efficient infrastructure is a key pillar for Vimond. We are always looking at new technologies, new capabilities in the cloud, and new ways to ensure that you can provide the best possible service to customers, with the minimum of spending on infrastructure.
Vimond cares about our customers´ wallets. Vimond wants you to have an efficient infrastructure, so that you have more money left to spend on content, analytics and capabilities that help you enrich the engagement with and experiences of your audiences.
In the above example, using the traditional method of guessing viewer volume at your busiest time, and then buying a bunch of extra, just for luck, you would pay for 30 compute pods, 24 hours a day, 7 days a week. You would pay for the entire surface area of the rectangle shown.
By targeting the most expensive pieces of infrastructure, the bits that use the most computing and processing power, and matching these to the underlying capabilities of the OTT CMS platform that use those pieces, Vimond has been able to selectively make parts of the platform auto-scaling. The infrastructure flexes and scales as you need, to meet the demands of your audiences.
This means that the cost to the customer of two essential components of the Vimond VIA platform have demonstrated cost savings of 82% and 67% respectively. This equates to thousands of dollars each and every month. And this is just an infrastructure saving. There are additional operational costs relating to data, logging, monitoring and security, which all get smaller with the reduction in infrastructure provisioning.
Vimond has focussed on ensuring that the most expensive pieces of infrastructure, the bits you need the most, typically those used for video delivery and personalisation, are kind to our customers´ wallets. Pay only for the infrastructure you need now, not the infrastructure you might need once a once a month.
It´s no secret that Vimond is a mature vendor in the CMS market. Our beginnings were as a team within TV 2 Norway, working at the forefront of what was technically possible in streaming video over the internet in the early days of the revolution (IPTV, OTT, TV Everywhere, etc….)
The software we were creating to serve audiences and viewers of TV 2 was revelationary, and attracted the attention of many of the major media and entertainment players on the world stage such as TV 4, MTV 3 Comcast and Kayo sports. This is what led to the initialisation of Vimond as an independent corporate entity in 2011, bringing our achievements out into the world, and enabling more broadcasters and content creators to benefit from adopting this early technology.
With such a journey, over a long period of time in a fast-changing world, it is inevitable that some early capabilities become legacy code, and that new emerging technologies make years-old design choices redundant. Changes in not just technology, but in software development and architectural frameworks and methodologies mean that sometimes, you have to take big chunks of once valuable, once innovative, once high performing market leading code, and tear it all up and start again.
And Vimond has done just that, with enormous parts of the Vimond VIA platform over the last four years. We went ´mediaeval´ and turned brutal on thousands upon thousands of lines of years old code, to shamelessly steal a phrase from a well known film…
The Vimond VIA OTT CMS platform, once a monolithic OVP, has undergone a major transformation. One that many other suppliers have yet to make.
Our once sprawling, though of course very effective, software, has been given not just the microservice architecture treatment, but also the cloud-native treatment, the regular deployment treatment and the faster time-to-deliver-value-to-customers treatment.
