Video: Building Media Systems in the Cloud: The Cloud Migration Challenge

Peter Wharton from TAG V.S. starts us on our journey to understanding how we can take real steps to deploying a project in the cloud. He outlines five steps starting with evaluation, building a knowledge base, building for scale, optimisation and finishing with ‘realising full cloud potential’. Peter says that the first step which he dubs ‘Will It Work?’ is about scoping out what you see cloud delivering to you; what is the future that the move to cloud will give you? You can then evaluate the activities in your organisation that are viable options to move to the cloud with the aim of finding quick, easy wins.

Peter’s next step in embracing the cloud in a company is to begin the transformation in earnest by owning the transformation and starting the move not through technical actions, but through the people. It’s a case of addressing the culture of your organisation, changing the lens through which people think and for the larger companies creating a ‘centre of excellence around cloud deployments. A big bottleneck for some organisations is siloing which is sometimes deliberate, sometimes intentional. When a broadcast workflow needs to go to the cloud, this can bring together many different parts of the company, often more than if it were on-prem, so Peter identifies ‘cross-functional leadership’ as an important step in starting the transformation. He also highlights cost modelling as an important factor at this stage. A clear understanding of the costs, and savings, that will be realised in the move is an important motivational factor, but should also be used to correctly set expectations. Not getting the modelling right at this stage can significantly weaken traction as the process continues. Peter talks about the importance of creating ‘key tenets’ of your migration.

Direct link

End-to-End Migration is the promise if you can bring your organisation along with you on this journey when you start looking at actually bringing full workflows into the cloud and deploying them in production. To do that, Peter suggests validating your solution when working at scale, finding ways of testing it way above the levels you need on day one. Another aspect is creating workflows that are cloud-first and translating your current workflows to the cloud rather than taking existing workflows and making the cloud follow the same procedures – to do so would be to miss out on much of the value of the cloud transition. This step will mark the start of you seeing the value of setting your key tenets but you should feel free to ‘break rules and make new ones’ as you adapt to your changing understanding.

The last two stages revolve around optimising and achieving the ‘full potential’ of the cloud. As such, this means taking what you’ve learnt to date and using that to remake your solutions in a better, more sustainable way. Doing this allows you to hone them to your needs but also introduce a more stable approach to implementation such as using an infrastructure-as-code philosophy. This is all topped off by the last stage which is adding cloud-only functionality to the workflows you’ve created such as using machine learning or scaling functions in ways that are seldom practical for on-prem solutions.

These steps are important for any organisation wanting to embrace the cloud, but Peter reminds us that it’s not just end users who are making the transition, vendors also are. Most technology suppliers have products that pre-date today’s cloud technologies and are having to make their own journey which can start with short-term fixes to ‘make it work’ and move their existing code to the cloud. They then will need to work on their pricing models and cloud security which Peter calls the ‘Make it Viable’ stage. It’s only then that they start to be able to leverage cloud capabilities such as scaling properly and if they are able to progress further they will become a cloud-native solution and fully cloud-optimised. However, these latter two steps can take a long time for some suppliers.

Peter finishes the video talking about the difference in perspective between legacy vendors and cloud-native vendors. For example, legacy vendors may still be thinking about site visits, whereas cloud-native vendors don’t need that. They will be charging using a subscription model, rather than large Capex pricing. Peter summarises his talk by underlining the need to set your vision, agree on your key tenets for migration, invest in the team, keep your teams accountable & small and seek partners that not only understand the cloud but that match your aims for the future.

Watch now!


Peter Wharton Peter Wharton
Director of Corporate Strategy,

Video: How Big Buck Bunny helped track down bugs

Early in the development of a streaming service, using a ‘mock’ player is a good way to be able to quickly test your code, in fact, it’s common to create mock API endpoints. The trouble with mocks is that they are too perfect as they lack the complex behaviour of a real player playing real media.

Evan Farina from LinkedIn explains what they’ve found while developing the LinkedIn video player. Communication from media players comes in the form of tracking events that indicate status such as ‘playing’ or ‘duration’. So when a player initiates playing of a video stream, a tracking event would come back to indicate success or otherwise. When using a mock, if your program works, so will the tracking event. In the real world, these values might be empty, have invalid data in or be functioning just as expected.


Once you’re in production, swapping your mock for real media has benefits. Evan explains that no longer needing to create/maintain a mock is a time saver. After all, it is code and you need to make sure it’s working and keeping up with production changes. But the main benefit is catching player integration issues and race conditions before releasing to production. Evan’s team found errors in tracking events, inefficiencies in the way media was being loaded and a dependency on free CPU which was previously unknown. All of this was possible before deploying into production.

How can you switch from mocks to real media? One goal is to ensure your tests aren’t reliant on any timing meaning your testing and the player need to be fully asynchronous. To do this, Evan’s created ‘helpers’ which control media playback (play, pause, seek etc) and also wait for a result with a timeout in case they never receive the resultant tracking event.

Evan finishes with some tips for scaling from his team. Firstly, there’s no point making your test take longer than necessary so keep media short. Second: store media locally to avoid network traffic not directly related to the test. Log all events since, at some point, these will be critical to understanding a problem. Lastly, he says to make sure you monitor your test servers since it’s important to make sure they’re not struggling to cope with the load which could affect the results of some of your tests.

Watch now!

Evan Farina Evan Farina
Software Engineer,