Maira Architecture

The below diagram describes a very high level architecture of Maira deployment.

The core is what we call workflow orchestrator that typically runs in the cloud. This contains many of Maira's core components such as API server, Site manager, Workflow server, Workflow workers etc. Maira's workflow server is based on Temporal's proven scalable technology.

The second component is Maira Gateway. This is a single process written in Go that runs completely in costomer premises. This component is the interface between Maira orchestrator and the services running on customer premises that Maira will integrate with. The gateway stores all customer credentials and other secrets so that they never have to leave customer's network. It connects with Maira Site manager when it starts up.

The end-user can interact with the Maira orchestrator in various different ways. These include: - Maira WebUI - Maira REPL shell - Slack Ops (other chat ops support coming soon)

Maira orchestrator also supports sending events to it through webhooks in many different applications that support sending webhooks, such as Prometheus, AWS CloudWatch, Google StackDriver, DataDog, Splunk etc. When an event is received through these webhooks, Maira will create or update an event in its database and run workflows that have been attached to that event type. All webhook messages are authenticated to stop a malicious users from creating spurious events and running workflows.

Maira Deployment with SaaS model

Maira supports two kinds of deployment: SaaS and On-Prem. In SaaS model, Maira runs the Workflow Orchestrator in its own GCP based cloud and Maira Gateway will still run in customer premises. This is a single process application that can be run in many different ways. The most simple is to run using Maira Gateway Helm Chart.

You need to update the values.yaml file to update various parameters. The maira section is to configure parameters needed to connect to Maira Site manager. It contains the following fields

maira:
  siteManagerAddress: "sitemanager.demo.maira.io:443"
  site: maira-site-1
  tenant: maira.io
  namespace: default
  api_key: key

siteManagerAddress is the address at which to connect to site manager. For our demo deployment, it is sitemanager.demo.maira.io:443. For our production deployment, it is sitemanager.maira.io:443. If you are using on-prem deployment, then use the public URL you chose for Maira deployment, or maira.localdev.me:3000 for non-public or laptop deployment.

site is unique name for your site. If you have more than one site, please make sure to pick a different name for each site, otherwise site manager will only pick one of those connections. Each site also needs to be approved by the customer in Maira dashboard before it is accepted.

tenant is usually the domain name of the company. E.g. If you work at google, this would be google.com.

namespace must be set to default. This feature is not yet available.

api_key can be created from Maira UI. Navigate to the sites page on Maira UI, then create new site. After that, click on the key icon to create a new key. Select a name for the key, select gateway as scope, select an expiry date (or leave blank for no expiry). Newly generated key will be shown, which can be copied and used in this field.

There are sections for each service that you want to use with Maira. Settings for each service differ based on the service, but typically include the host name of the service and credentials for that service. If the service needs any other parameters (e.g. AWS region names), those are also to be configured in that section. Please refer to integration page for each service to see the details for what all needs to be configured for that service.

If you don't want to deploy on kubernetes, another option is to run it in a VM. Maira supports systemd to run the Gateway

Maira On-Prem Deployment

With Maira's On-Prem deployment, both Orchestrator and Gateway will run in customer premises, though still managed by Maira. This allows customers to have a complete deployment dedicated to their services, and their data will never leave their premises.

For this option, please follow instructions at our gitops repo: gitops

With this model, Gateway still needs to be installed similar to SaaS model, but for deploying Orchestrator, we support ArgoCD based deployment.