Technology Special: BLAM Behind the (Beautiful) UI

As an organisation Blue Lucy tends to focus on the business of media operations.  The BLAM platform is operationally focused and every function of the platform can be mapped to a business benefit in our requirements schedule.  We rarely talk about BLAM in terms of technology as operationally it doesn’t matter how it ‘works’. However, as the first deployments of BLAM-3 – the third generation of product – go into operational service it’s a good time to provide a little insight into the development in a techie’s special blog.

Background

BLAM-3 is a ‘ground up’ rebuild of BLAM which began in early 2017 and was motivated by a desire to increase the workflow functionality and overall system scaling beyond the capability of the technology on which the original product had been built.

Rather than continue to sweat the core code-base as so many software companies do, we decided to take a clean sheet of paper to the design and build of the new platform. Zac Sloss the lead developer for BLAM-3 says “it’s slightly daunting, as well as exciting when you first click new project in Visual Studio.” but, in truth, this approach is actually easier and cleaner than building on an existing code-base.  In this context BLAM-3 is truly, completely new, although many of the core features of BLAM-2 have been carried across from a functional perspective.

BLAM-2 had evolved over a number of years and, although remarkably feature-rich in the competitive market, the ambitions for the product into the 2020’s were beyond the technologies on which it had been based – in short there existed easier ways to achieve the same functional outcomes.

The product management team wanted BLAM to support a true multi-tenant operating model so that Blue Lucy could offer BLAM as a low-cost, managed SaaS offering to smaller operators.  Our service-provider customers such as TVT and PlazaMedia, were also keen to offer services to multiple-client operators on a single platform, safe in the knowledge that users and media were properly and logically separated.

There were also great ambitions for the workflow component of the product.  This capability had evolved dramatically over the lifetime of BLAM-2, growing to supporting more than 80 functional BLidgets – Blue Lucy widgets.  The product team see the integration with other platforms and services as the most important feature of the product in the near and mid-term.  Integration is affected through BLidgets and, as such, the new BLidget short-list got to 150 within a few hours in the early design sessions.  A new approach to building BLidgets was needed to support a significantly larger, scalable development team without the integration headaches such scale can cause.

These features alone justified the clean sheet of paper approach for the research and development team.  From a business perspective it made total sense also: the value of the business and the platform proposition is not in each line of code it is in the experience and knowledge of how to put it all together – there are many years’ worth of knowledge inherited from BLAM-2 in BLAM-3, if none of the code.

Principals

BLAM-3 follows the 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 3^rd party system to connect to – we can implement the capability extremely quickly.

Within the BLAM-3 core there is a further abstraction between the workflow runner and the BLidgets.  This is the most significant organisational improvement over BLAM-2.  BLidgets which perform specific functions when run in the workflow engine are now 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 business unparalleled development scale and means that BLidgets may be developed by third parties – see SDK, below.

Technology

The platform is underpinned by .NET core 3.0, the latest .NET framework from Microsoft which affords a truly cross-platform, open source, common language run-time environment.  .Net core 3.0 provides us with long term supportability, an excellent security model and true enterprise level robustness.  In the detail there is a 40% performance improvement over .NET 2.2, excellent memory management and 3.0 has numerous optimisations for containerised deployments which fits with the need for scale in multi-tenant cloud deployments.

Entity Framework Core 3.0 was chosen as the object-relational mapping framework and allows BLAM to be backed by a wide range of databases, so on-prem’ deployments can be customised 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 manually written queries.  We leverage 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.  – e.g. sports logging.

For the web-browser based front-end we use the Angular 8 TypeScript-based framework from Goggle.  The framework is a good fit for .NET Core 3.0 and provides an optimal user experience. We have also used SignalR 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.

SignalR provides highly efficient and instantaneous real time status updates to the Workflow Monitor

The BLidget SDK

We have recently released an SDK to allow software developers to build BLAM BLidgets to run in the BLAM workflow engine.  This is a major step in opening up BLAM to extend the ecosystem to drive more business value for operators by allowing anyone to write their own BLAM plug-ins.

BLAM-2 had an open REST API as well as the capability for developers to script C# and execute that in a workflow.  We have preserved both of those features in BLAM-3 with enhanced API documentation using Swagger, but we have gone one step further and released the full SDK for C# developers.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 3^rd party library.  When the BLidget code or function is written, it is bundled using our publishing tool and may be deployed to the BLAM – it is immediately available for use in the workflow builder.

This is more powerful than simply calling the BLAM API, as it utilises the BLAM workflow engine to perform any 3^rd 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 you know it’s good, and we shall soon be releasing versions for Python, JAVA, Node.JS and F-Sharp.

From a business perspective, the SDK allows us to extend the capability of BLAM, 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.

The BLAM Blidget SDK in Visual Studio

The BLAM API is documented with Swagger

BLAM is an operations management platform that is focused on streamlining a media business’s content operations and, as such, the technology shouldn’t matter.  Technology is important though and we hope this short insight from our engineering team into the design and construct of BLAM-3 highlights the modern, scalable and easy to integrate SaaS offering it is.

If you would like to learn more about BLAM technology, or our SDK, or if you are interested in joining our growing technology team in a development or implementation role, please do get in touch.