Technology
Blue Lucy focuses on the business of media operations. BLAM has been built from an entirely operational focus and we rarely talk about BLAM in terms of technology.
The architecture of the platform and the tools we have used to build it are important. Our approach delivers enterprise software which affords scalability and extensibility unprecedented in the media and broadcast industry.
Design Principals
BLAM follows a distributed microservices architecture, meaning the overall BLAM capability is structured as a collection of loosely coupled services. The architecture is robust, resilient and conforms to the separation of concerns paradigm. The singularity of purpose which is a key tenet of separation means, overall, BLAM is easier to maintain and extend. Equally there are opportunities for re-use of components which speed up our development so that as new customer requirements come in – such as a new 3rd party system to connect to – we can implement the capability extremely quickly.
Within the BLAM core there is a further abstraction between the workflow runner and the BLidgets. BLidgets which perform specific functions when run in the workflow engine are isolated from the engine itself. This enables BLidgets to be developed independently of the workflow engine and provides an extra level of safety at run-time. Given that 80-90% of the future development of the platform will be in BLidgets, this gives the Blue Lucy business unparalleled development scale and also means that BLidgets may be developed by third parties – see SDK, below.
Software Frameworks
The platform is underpinned by .NET core 6.0, the latest (and fastest) .NET framework from Microsoft which affords a truly cross-platform, open source, common language run-time environment. .Net core 6.0 affords long term supportability, an excellent security model and is optimised for containerised deployments providing true enterprise level robustness.
Entity Framework Core is used for the object-relational mapping framework and allows BLAM to be backed by a wide range of databases, so on-prem’ deployments can be tailored to customer-specific needs. The framework is optimised for rapid development – we do not need to directly create the underlying tables – and provides excellent operational performance. The abstraction from the database layer provides not only portability but means that the core BLAM code is leaner as it does not contain numerous ‘hand-written’ queries. We utilise the built-in concurrency management which maintains data integrity: very important in large scale media operations in which data may be rapidly updated from multiple human and machine sources such as sports logging.
For the web-browser based front-end we use the Angular 11 TypeScript-based framework from Google. The framework is a good fit for .NET Core and provides an optimal user experience. SignalR is used extensively in the user interface to provide real-time status updates. SignalR eliminates the need for polling from the front-end to reduce chatter and provides users with instantaneous operational status updates – this is particularly powerful demonstrated in the workflow monitor view.
All user interfaces in BLAM are updated in real-time using SignalR. Above the Workflow monitor
Truly open to integration
BLAM has an open REST API supported with enhanced documentation using Swagger and is additionally supported by a full SDK. The SDK allows software developers to build BLAM BLidgets to run in the BLAM workflow engine. This extends the BLAM ecosystem to drive more business value for operators by allowing anyone to write their own BLAM plug-ins.
The BLIDGET SDK
Available as a package from NuGet the developer-friendly .Net Core SDK allows engineers to code in their preferred IDE, such as Visual Studio, and provides features such as IntelliSense, enabling rapid and predictable development. The SDK supports rapid learning, with standard methods for accessing data, and provides a safe interface as the commands interact with the BLAM API rather than lower level. The SDK allows developers to use any .NET Standard library which provides the freedom to integrate any 3rd party component. When the BLidget code or function is written, it is bundled using our publishing tool and may be deployed to a live running BLAM. On deployment the new BLidget is immediately available for use in the workflow runner without the need to stop any ongoing operations.
Using the SDK is more powerful than simply calling the API, as it utilises the BLAM workflow engine to perform any 3rd party function or interaction. This has the potential to extend the useful functionality of the platform way beyond the usual broadcast systems. The public SDK is the same tool that we use internally so it is proven and is regularly updated.
A Python SDK was released in 2021 and further SDKs will be made available in 2022 for JAVA, Node.JS and F-Sharp.
From a business perspective, the SDK allows us to extend the capability of BLAM at tremendous scale, but it also means that integration of proprietary systems is greatly simplified. The approach de-risks projects which involve integration with proprietary or unsupported systems.
release management
In development Blue Lucy follows continuous integration principals which drives a modular development approach and ensures robust outcomes. Equally software updates, which are automated to Blue Lucy managed cloud systems, follows a continuous delivery paradigm with updates to the BLAM core services occurring monthly. As BLidgets are abstracted from the core these may be released to active systems as required. Where possible all BLAM platforms are updated automatically and with zero ‘down-time’.
Kubernetes Continuity
Blue Lucy use Kubernetes for the deployment of BLAM which supports the continuous service and delivery model.
Kubernetes is an open-source container orchestrator used for automating the deployment and management of containerized applications. A containerised application is a stateless application that is not dependant on persistent local data storage. The lack of data persistence for containers has multiple benefits including the ability to scale and load balance between many containers of the same type.
BLAM utilises the benefits of containerisation and takes it further as individual components of the platform are themselves containerised. There are 6 key components to a BLAM deployment:
- API – is the controlling interface
- Workflow Runner – for automation and compute
- Microservice Plug-ins – for 3rd party integrations or compute and I/O intensive tasks
- User Interface – the front-end the operators work with
- Database – for application data persistence
- Storage – the media repository
Components 1, 2 and 3 are completely stateless by nature so may be independently scaled depending on the operational requirements. Coupled with Kubernetes, to manage the deployment of the containers, if a function of the platform is ‘bottlenecked’ by load or demand this may be quickly and simply alleviated by deploying additional containers to increase the overall system capacity. Load balancing occurs automatically without any impact on the operator’s user experience.
Kubernetes supports BLAM platform updates without operational downtime, essential in 24/7 business. Kubernetes does this by deploying and starting updated containers alongside existing containers before stopping the old containers. The old containers remain offline but available to re-start if the update needs to be roll-backed or the update fails/stops mid-deployment. By rolling up the update in this way, there is no observed downtime from the operator’s perspective ensuring continuous service.
It is in components 5 and 6 where the separation of concerns approach pays dividends. BLAM-3 is database and storage system agnostic. Interaction with the database layer is abstracted using Entity Framework Core meaning BLAM-3 can use a database solution appropriate to the operations scale or customer preference. Cloud provisioned database services are ideal for deployments that need to scale, and these models offer a number of other benefits such as resilience, load balancing and backup without the overhead of in-house database administration.
Storage access and interaction is managed through BLidgets and microservice based plug-ins. The platform stores customisable configuration information in the database which can then be accessed and used by BLidget and plug-ins through the SDK.
BLAM has been designed from outset with a focus on scalability. By discretizing services and compute from the data layer into containers and leveraging the load-balancing and management offered by Kubernetes, BLAM provides operationally continuous service but is truly configurable and readily maintainable.