IP Security For Broadcasters: Part 10 - NATS Advanced Messaging

As IT and broadcast infrastructures become ever more complex, the need to securely exchange data is becoming more challenging. NATS messaging is designed to simplify collaboration between often diverse software applications.

All 12 articles in this series are available in our free 82 page eBook ‘IP Security For Broadcasters’ – download it HERE.

Articles in this series:

In this context, the acronym NATS stands for Neural Autonomic Transport System, as the structure of the messaging platform is said to function like a central nervous system. It’s important to note that this is a completely different solution than the NAT (network address translation) systems for IP addresses. It solves an entirely different problem.

Moving to virtualized environments and datacenters requires broadcasters to think completely differently about their infrastructures. To achieve the flexibility, scalability, and resilience that cloud computing promises, whether public or private, requires software to be written with virtualization in mind from the outset, not as an afterthought.

Virtualization has led to the development of software disciplines such as microservices working in containers. This is a complete change from the huge monolithic code base of previous years where scalability often relied on supplying ever larger servers. The beauty of microservices is that they can be deployed horizontally, that is, more servers of moderate power are deployed as opposed to a few huge servers, thus simplifying scalability.

Microservice Communications

For monolithic code, functions resided within the same compilation so exchanging data between them was relatively straightforward. However, as we move more to microservices and the philosophy of thinking they promote, programs must now communicate with each other outside of their codebase and often on entirely different domains. In essence, each microservice works in isolation but must still communicate with its counterparts.

One messaging solution is to use REST API communications. These are software interfaces that use HTTP messages such as GET and POST to exchange data. Although this is a well-proven technology and is used extensively, it tends to have limitations for scaling. For example, a resource-monitoring microservice may be requesting monitoring data from a single transcoder every second. This is easily achievable with REST APIs. If the number of transcoder-microservice instances increases to one hundred, or a thousand, however, then REST APIs start to show their limitations, especially in public cloud infrastructures where costs are predicated on the number of HTTP requests.

NATS messaging solves this type of scenario by using an advanced type of messaging system based on the client server model. It’s open source, scales well, and provides secure channels with the option of user client authentication.

Simple Messaging

In its simplest deployment, a NATS system will consist of two clients and a NATS server. A client will publish messages, and other clients known as subscribers will listen and opt in to receive them. This gives the potential of one-to-many broadcast type messaging, as well as querying. 

Figure 1 – NATS servers can be configured to provide scalability and resilience using virtualized servers that operate independently of the underlying network and infrastructure.

Figure 1 – NATS servers can be configured to provide scalability and resilience using virtualized servers that operate independently of the underlying network and infrastructure.

In the transcoder-microservice example, the monitoring service will publish a request-monitoring-data message to the NATS server which will in turn broadcast the message to the clients subscribing to this service (part of the configuration of the transcoding service will be to enable it to listen for monitoring broadcasts). On receiving them, the transcoders will each send their monitoring data back to the monitoring service via the NATS server.

Messages may also be point-to-point or many-to-one, as used when sending the transcoder monitoring data back to the monitoring microservice. But key to this deployment is the ability to both secure the communication channel and scale the system using the distributed resource mindset.

Message Scaling And Resilience

NATS is a middleware deployment, that is, it is independent of the underlying hardware infrastructure. This is particularly useful when scaling systems: new NATS servers can be easily deployed within a virtualized environment as it is lightweight and compact in terms of its resource utilization (see figure 1).

To improve resilience and scalability, NATS servers are clustered to provide main and backup systems as well as extra resource. A cluster of three NATS servers could be configured to provide one main NATS server and two backup servers, or three servers each acting as a client connection, or a combination of these.

Also, several clusters of NATS servers could be connected but geographically dispersed. For example, three clusters could be configured, one in Europe, one in US West Coast and one in US East Coast. Not only does this method provide local redundancy, it also provides scalable resources using virtualized servers that can be spun up and down at will.

It’s important to note that the NATS system is a message exchange method and not necessarily designed to shift large amounts of video and audio data. It is possible to achieve this, but a far better use of resources is for the microservice to read and write the media data directly to and from the storage servers. The relevant messages will be exchanged between the software applications connected to the NATS servers to provide location information for the media storage.

Keeping Messages Secure

Security is at the core of NATS and message connections can be encrypted with TLS. Also, client connections can be authenticated in several ways including Token Authentication, username/password credentials and TLS certification.

Authorization tokens are the equivalent of a stamped ticket to an event and are created when a user verifies their credentials. Once this is done, the token is used to access servers, storage, applications, and APIs thus freeing the user from logging in each time they need to access a particular service.

A centralized administration resource creates unique tokens based on a user’s login credentials with the appropriate read/write access. This is particularly useful for services exchanging messages between APIs as the token is sent with the message, allowing the receiving service to verify the request and provide the appropriate access.

NATS advanced messaging has been developed to simultaneously solve the challenges of allowing software applications to securely exchange messages while achieving scalability, flexibility, and resilience.

Part of a series supported by

You might also like...

Designing IP Broadcast Systems: Part 3 - Designing For Everyday Operation

Welcome to the third part of ‘Designing IP Broadcast Systems’ - a major 18 article exploration of the technology needed to create practical IP based broadcast production systems. Part 3 discusses some of the key challenges of designing network systems to support eve…

What Are The Long-Term Implications Of AI For Broadcast?

We’ve all witnessed its phenomenal growth recently. The question is: how do we manage the process of adopting and adjusting to AI in the broadcasting industry? This article is more about our approach than specific examples of AI integration;…

The Big Guide To OTT: Part 10 - Monetization & ROI

Part 10 of The Big Guide To OTT features four articles which tackle the key topic of how to monetize OTT content. The articles discuss addressable advertising, (re)bundling, sports fan engagement and content piracy.

Next-Gen 5G Contribution: Part 2 - MEC & The Disruptive Potential Of 5G

The migration of the core network functionality of 5G to virtualized or cloud-native infrastructure opens up new capabilities like MEC which have the potential to disrupt current approaches to remote production contribution networks.

Standards: Part 8 - Standards For Designing & Building DAM Workflows

This article is all about content/asset management systems and their workflow. Most broadcasters will invest in a proprietary vendor solution. This article is designed to foster a better understanding of how such systems work, and offers some alternate thinking…