Robert Nagy Archives – The Broadcast Knowledge

A lively conversation today on updating workflows, upskilling staff, when to embrace the cloud…and when not to. Started by a discussion on Reddit, we hear from CEO of Canadian service provider Nextologies, Sasha Zivanovic and co-founder of Nxtedition, Robert Nagy. The discussion, hosted by Adam Leah, starts by tackling the question of how to deal with legacy workflows. The initial disagreement seems to come from the two approaches. Robert’s pragmatic approach acknowledges that legacy workflows can be functional and dysfunctional and the decision on whether to start again or transition lies in whether your current workflow works without constant human intervention or not. Sasha agrees that dysfunctional workflows, ones that fall apart if key people are away, need to be dismantled and reworked at the earliest opportunity. Otherwise, he feels that education is key in ensuring that you teach people how to use the new technologies available and how to create good, robust workflows on which you can really base your future business.

Indeed, for Sasha education is the key because, in his words, ‘there is no 1-800 Amazon’. Being progressive and moving your workflow into the cloud may be the right way forward, but understanding that the cloud providers are only providing infrastructure means that if any little thing doesn’t work, you will need your own staff to explain it and resolve the problem. Even big players who may have access to named Engineers will still have far too many smaller issues that they themselves will have to deal in order to allow their named resources at the cloud provider to work on the higher priority/bigger problems and designs being discussed. Moreover, lack of education is more likely to lead people simply to go with what’s easy namely making something work using free/low-cost hardware and software. Sasha’s point isn’t that free things are bad, but that often the solutions based on getting OBS up and running are often not robust and may accept more compromises such as latency of image quality, than needed.

Robert and Sasha go on to discuss this question of what quality is good enough directly, both advising against superfluous quality as much as recommending avoiding workflows that under spec the stream. Quality needs to come down to your brand, the video’s context and the technical capability of the workflow. To speak to the latter, both Robert and Sasha point out the folly in demanding archives and contribution happen in the ‘house format’ such as 25Mbps. Such bitrates may make a lot of sense on-prem, but for streaming or some cloud workflows are counterproductive and don’t deliver a better result to the viewer. Your brand does need to be considered in order to set a lower bar for the content, but usually, the venue of your video is more important, agree Robert and Sasha, where a YouTube Story would attract a different quality to a Vimeo post to a long-form OTT asset.

The larger concern raised in this conversation is the ‘bifurcation’ of the market. Looking at this from a service provider’s point of view, Sasha sees that the tech companies have increased the size of the market which positive. But with that comes problems. The ease of access to the cloud increases the ability for small players to participate but there is still a high-end place in the market where tier-1 broadcasters play who do benefit from the cloud, but still requires a high investment in time and design to create it along with high Opex. This doesn’t mean overall there is no cost-benefit to those broadcasters, often there is and sometimes it’s not cost they are optimising for. But it’s the gap that concerns Sasha, where those not engaging like tier-1 broadcasters tend to graduate to the bottom end of the market which has much lower revenues than before. Whilst The Broadcast Knowledge would suggest this is where Sasha can prove the worth of his company, anchoring the bottom of the market at a low cost does reduce the opportunities for companies such as Nextologies to charge a sufficient amount to cover costs and maintain competitiveness. Robert and Sasha both agree that that success with clients nowadays is achieved through partnering with them and following, helping and encouraging them on their journey. The value of such a long-term design or product partner is worth more than any single workflow.

Watch now!
Speakers

	Sasha Zivanovic CEO Nextologies
	Robert Nagy Lead Developer & Co-founder, nxtedition
	Moderator: Adam Leah Creative Director, nxtedition

Promising to simplify programming, improve resilience and redundancy, Microservices have been moving into the media and broadcast space for several years now adopted by names such as EVS and Imagine Communications as well as being the focus of a joint project between SMPTE, EBU and Open Services Alliance. This video explains what microservices are and why they can work well for media & entertainment.

In this video from nxtedition, Roger Persson introduces colleagues Robert Nagy and Jesper Ek to answer questions on microservices. Microservices are individual, independent programs that talk together to create a whole system. They stand in contrast to monolithic programs which have many functions in one piece of software. Splitting each function of a program into its own microservice is similar, but better than modularising a monolithic program since you can run any number of microservices on any hardware leaving you able to create a dynamic and scalable program across many servers and even locations.

Jesper explains that microservices are a type of modular software design, but with the lines between the modules better defined. The benefit comes from the simplicity of microservices. Modules can still be complex but microservices are small and simple having only one function. This makes testing microservices as part of the development workflow simpler and when it comes to extending software, the work is easier. Using microservices does require a well-organised development department, but with that organisation comes many benefits for the company. One thing to watch out for, though, is that although microservices themselves are simple, the more you have, the more complex your system is. Complex systems require careful planning no matter how they are implemented. The idea, though, is that that’s made all the easier due to the modular approach of microservices.

With so many small services being spawned, finishing and being respawned, Roger asks whether an orchestration layer is necessary. Robert agrees this is for the best, but points out that their approach to an orchestration can take many forms from ‘schedulers’ such as Docker Swarm or Kubernetes which take your instruction on which microservices are needed on which hardware with which properties. Up to more complex options which abstract the workflow from the management of the microservices itself. This can work in real-time ensuring that the correct microservices are created for the workflow options being requested.

The ease of managing a live microservice-based system is explored next. Each part is so small, and will typically be running several times, that services can be updated while they are live with no impact to the service running. You can bring up a new version of the microservice and once that is running kill off the old ones either naturally as part of the workflow (in general services will never run more than 15 minutes before being closed) or explicitly. Failover, similarly, can work simply by seeing a hardware failure and spawning new services on another server.

Because of this indifference to the underlying hardware, Microservices can be spun up anywhere whether on-premise or in-cloud. Cloud-only services are certainly an option, but many companies do find that low-latency, high-bandwidth operations are still best done on-premise close to the source of the video. The cloud can be used to offload peaks or for storage.

As ever, there’s no one solution that fits everyone. The use of microservices is a good option and should be considered by vendors creating software. For customers, typically other aspects of the solution will be more important than the microservice approach, but deal-breaking features may be made possible or improved by the vendor’s choice to use microservices.

Watch now!
Speakers