¶ 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.This section describes the basics of Busby, looking at microservices, messaging, the benefits of centralised configuration and Busby’s core capabilities.
Alternatively, if you wish to explore the core capabilities
of a Busby system then click on the following links.
¶ Messaging
At its heart Busby is built upon a messaging framework – https://www.rabbitmq.com. 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.
This is stored in a versioned https://www.elastic.co/elasticsearch/service" database.
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.
¶ Core capabilities
Built on top of the base Busby system are several components that make common tasks easy to implement.
¶ Alarms
Busby Alarms are built on the messaging and monitoring capabilities of the Busby core. They can react to alarms from any connected equipment, be triggered by a Busby process or provide the user with details about the health of their system.
¶ Boards
Boards are essentially the visual representation of a Busby workflow. Using a Kanban layout, a workflow step is shown as a column and cards within each vertical strip as a job.
¶ Dashboards
Dashboards allows you to easily design your own information screens that display the current performance status of your Busby system and provide instant feedback on any service.
¶ Forms
Busby Forms are fully customisable to allow user input.
¶ Reporting
The Busby Reporting features allow you to examine all aspects of the Busby system. Behind the scenes Busby is always tracking data as it moves through steps in a workflow or interacts with other services. Each report can be tailored to your requirements, easily accessed and always displaying the level of detail that you need.
¶ Resources
Resources allow you to add your own bespoke datastore to Busby. You can easily design a series of related resource types with the aid of the intuitive graphical editor.
¶ Scripting
Scripting provides ways of adding customisable behaviour to a Busby install. It can be plugged in to various parts of Busby such as as a workflow step, as a standalone nano service, and much more.
¶ Workflow
Busby Workflows are built on the messaging and monitoring capabilities of Busby core. They allow you to create, customise and deploy workflows with a mixture of your own bespoke Busby components or integration with third party systems.