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 3rd 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 experie
