¶ Feature Rich
Make custom workflows, trigger alarms, create resource databases, enhance with simple script. Built to solve all sorts of media integration problems.¶ Interactive
Mix automated and manual tasks. Live updating boards, workflow tasks, reporting and much more.¶ Enterprise Ready
Built from the ground up as an enterprise microservices platform. Make systems that can scale from one service up to 100s or 1000s. Choose your redundancy level. Run on-cloud, on premise or a mixture.Busby is an enterprise-ready integration platform, designed particularly for broadcasters and media companies.
At its core Busby provides messaging between services across a microservices framework and a configuration toolkit to facilitate software and services deployment.
This section describes the basics of Busby, looking at microservices, messaging, the benefits of centralised configuration and Busby’s core capabilities.
¶ Messaging
At its heart Busby is a messaging framework. This framework is used to set up the necessary communication channels between the various services on a system. The complexity of the messaging implementation is hidden behind a simple abstraction of services, providers and subscribers.
The general concept is that services provide capabilities that can be called upon.
Providers run pieces of code that instantiate or call upon a service.
Meanwhile, subscribers connect to services to use the services capabilities.
The following diagram shows the routes of various messages in an alarm system.
Each service can be provisioned across multiple providers. When a subscriber attaches to a service, the exact provider that it connects to is unknown. This inherently flexible messaging mechanism can change call by call and allows service level redundancy and load balancing.
Behind the scenes a directory service determines the messages that flow between both provider and subscriber. The directory service also acts as a directory of the providers that are available and whether they can receive requests.
Once a connection is established, messages are directly routed from subscriber to provider.
¶ Message types
Busby restricts the types of messages through the bus to two types, first request and response, here a question is asked by a subscriber and a provider responds; second status messages, in this case subscribers can register for interest in status from a provider and get an unsolicited message each time an event of interest happens. These two mechanisms
use simple JSON payloads. Anything more complex in terms of message orchestration is configured in the business logic, normally in a workflow.
¶ Microservices
Implicit in the discussion of messaging is that there are applications that need to talk to each other. In a Busby system these are microservices, each microservice sits on the bus and talks to other microservices through the messaging layer.
Microservices come in a few varieties
- built in - core microservices delivered with all systems, eg authentication service, directory service
- per project - microservices built to carry out a particular function unique to a deployment. These can be written in Java, JavaScript (TypeScript) or C#.
- nanoservices - Busby provides an in-built way to create very simple services through scripting, these are akin to lambda expressions.
¶ Persistence
Sometimes microservices need to persist data across time, in general there are two ways this is accomplished within Busby.
-
Using a database - in this case the database is always hidden behind the service, all requests to retrieve or update data should go to the service layer, and the service should then write to the database. The database should never have more than one service connected to it. The rationale behind this approach is described at the https://microservices.io/patterns/data/database-per-service.html site. Database redundancy across the bus, changes to an active DB are transmitted as status messages to all standby providers.
-
Using busby.cache - Busby provides a simple mechanism to store data through calls to a busby.cache service. This is appropriate for small amounts of data that needs to be persisted for a short time.
¶ Configuration and deployment
As microservice systems become more complex, with more and more integrations, it becomes increasingly necessary to effectively manage them. Each microservice has its own configuration and this in turn would be different on each deployment environment. Very quickly the associated management overhead would soon become impossible.
Busby provides a centralised configuration system that is managed through a single web portal.
Each microservice that is deployed has associated configuration that defines its behaviour.
When a microservice starts it only knows two things, first its own name, and secondly the contact details of the configuration service. Initially, the first question it asks is ‘what is my config?’. This is then used to configure everything else.
When the configuration changes in Busby, a status message is sent out to all services to say that new configuration settings are available. Each service then decides if it needs to re-read its configuration and reconfigure itself accordingly.
When a configuration is published through the Busby configuration editor, a particular deployment is chosen. This deployment defines the environment that is being updated - eg QC, production, dev etc. In certain cases values need to be modified depending on the deployment. Busby makes this simple through the use of deployment based variable substitution - which really just means that configuration values can be one thing on one deployment and something else on another. An example would be if connecting to an external REST API, the endpoint might be different for the development environment as opposed to
the live system.