The launching of a product, or where I've been for the last few years

Published on 2023-6-1

Rejoice!

I have somehow managed to revive my blog without having to write any code, change any CSS or do any busy work at all thanks to the miracle of Github pages and the fact that my website was always just a pile of static pages generated by some terribly written JS that hasn't changed in nearly a decade - who says code rots?

Where the hell have I been?

I'm honestly quite surprised at how many people have reached out over the last few years to ask this question - I can either consider this a testament to how much impact I've made over those years, or simply because I've always been a noisy person and any silence from over in my corner is deafening.

The answer is that it turns out that when I'm actively engaged in writing software that people are actually going to use and I'm being fulfilled by that task, that I really don't feel the urge to try and talk about software development with people. The fact is I've spent nearly a decade now helping our customers with their bespoke media workflows and that job has been all the software development chat that I really need in my life.

The last few years we've been heads down productising (is this a word?) the knowledge and code we've built up over the years so that our potential customers (who often already have software teams of their own) can start to build out some fairly advanced capabilities without having to become media technology companies themselves and without them having to teach us everything about their business.

Those were definitely some words

There are a lot of off the shelf media technology solutions out there for performing a wide variety of tasks, and they are typically (because of the complexity involved) fire and forget "set it up and forget about it" systems. Media is messy and there are a lot of media products out there who are responsible for taking content from a variety of sources, packaging up that content and then distributing that content to end users so it can be consumed.

A starter solution for fledgling companies who reach the limits of these black boxes might be to write some scripts to glue these tools together (often using ffmpeg), and while this might get you so far, sooner or later this approach runs out of steam and somebody needs to write some actual code.

At this point you've got two options - you can perform this task in-house and take on the complexities that this involves (hint: this is a dangerous path!), or you can take on the services of one of the many systems integrators out there and get them to do this for you with all the in-house expertise they have, exchanging the cost of technical ownership for a simple license or service fee.

We (id3as) have always taken on the more challenging of these jobs, the jobs that others would maybe consider to be technically expensive and the jobs that have maybe even already been attempted by others to little success. We have been unafraid to use new (and old) technologies to solve problems and because of our experience and existing codebase we often find that the bulk of the effort is in the understanding of the business requirements of our customers rather than the technical challenges presented by the media itself. And isn't that the rub? The people with the business knowledge that know what they want are the best people to be building software around their own requirements, but the people who know how to deal with the complexities of fairly involved media workflows are external to that. For our own sins this often means we end up with customer logic inside our shared code out of necessity because everybody has a different idea about how fairly basic operations should take place (quality of service controls, pid mapping, source failover, etc).

We have repeatedly for our own benefit attempted to separate these concerns in order to better be able to respond to the needs of our customers without burying ourselves in complicated configuration and while we have always managed to get to somewhere better than we were, we haven't (until recently) come up with a platform that really delivers this.

Enter Norsk

The trinorsk Mascot (a blue triceratops wearing a viking helmet with three horns..

I'm not entirely sure how it happened - we were taking our existing stack and upgrading it to help us maintain our own velocity (that's when we started heavily using Purescript for those that have been paying attention!), and in the process of doing this we started to see the shape of a product that we could use to keep our customer's business logic and the complex media orchestration separate and wholeheartedly pursued it.

Not only did it make sense, but it started to look as though we might be able to let other people use this platform to build their own complex workflows and that was incredibly exciting to us - obviously we did the only sensible thing at this point and committed to it - using it to do a few jobs for our existing customers as well as sharing it with a few trusted partners to see what they made of it.

The result of all this is that we're now shipping a product comprised of some incredibly clever technology written in a language that helps us avoid failure (Purescript), built on a platform that makes its name out of handling failure when it happens (Erlang) and allowing business logic to be written in a universally understood language (Javascript/Typescript) whilst taking care of the nitty gritty details of workflow management and ensuring automatically that customers have all the introspection, logs, metrics, and debugging tools that companies have come to expect in modern distributed systems. As we always have done, we integrate directly with the codecs we use and implement most protocols ourself so we have the power to work with the "nuances" of other implementations and as a result of this we have a flexibility to respond to challenges that is hard for a lot of people to fathom.

In a nutshell

You spin up a Norsk server, connect to it over the Typescript SDK and say

That last section is probably the most interesting - instead of fire and forget configuration, every decision that Norsk makes about media flows through the client application - a new stream appears and the client application is asked "where do you want this to go?", metadata changes and the client application is asked "does this change what you want?", various control nodes can flow frame by frame information to the client and allow it to respond in realtime to events in the media and update config across any node without causing any service interruption.

Norsk takes care of the media technology problems such as orchestration, codec knowledge, protocols and conversions and the client application gets to take care of decisioning and control - this is somwhat revolutionary. I several times over a recent conference where we launched the product tongue-in-cheek simplified this to "it's like being able to run ffmpeg and change everything about anything while it's running", but even that's a gross simplification of what Norsk actually gives the customer.

I'm really excited about what this means for the streaming industry and I'm really excited to see where we end up taking it. We have a lot of capability in our core platform that isn't yet exposed in Norsk so we're only really starting out in our task to place that power in the hands of our clients.

Anyway - I'll be doing various technical blogs about Norsk and related subjects in the coming months over at the Norsk Blog, and I'd be delighted if anybody were to join me over there for that.

2020 © Rob Ashton. ALL Rights Reserved.