Deployment architecture

• A DNS setup provides a mapping of your domain names toward a load balancer.

• A load balancer of your choice, like Azure and AWS’s default ones or MetaILB.

• An ingress controller of your choice like Traefik or ALB (Amazon).

• A Kubernetes installation on a cluster of both Linux and Windows Virtual Machines (nodes).

• A database of your choice, such as Microsoft SQL Server, Azure SQL Database, Oracle, DB2, or Amazon Aurora (MySQL).

The Kubernetes command-line interface (Kubectl, or any tools built on top of it) allows your administrators to run commands toward the Kubernetes cluster. This includes the deployment of Genus microservices, inspection and management of cluster resources, and the ability to view detailed logs.

The Helm command-line interface (CLI) is used by your operations team to manage Genus releases in the cluster.

The Helm command-line interface (CLI) is used by your operations team to manage Genus releases in the cluster.

Genus uses an Azure Container Registry to store Genus container images ready for deployment into your cluster.

Genus connects to a range of ID Providers for secure access to the cluster.

Genus utilizes the standard high-availability features within Kubernetes, which basically comes down to setting up multiple Kubernetes master nodes, and a sufficient number of pods for each service spread across underlying nodes, the Ingress controller service included. Your load balancer and DNS also need to be set up with standardized high-availability features.

To provide disaster recovery one needs to set up clusters and databases in multiple regions or availability zones with configuration, data replication, and backups. Although this is perhaps most easily achieved using one of the large cloud vendors like Azure or Amazon, also third-party vendors can set this up. This is because all the underlying technologies of Genus, like the database systems and cluster software, are standardized and come with the necessary mechanisms to support disaster recovery.

You are also free to define the level of application isolation you require. If you have multiple Genus applications in your organization, these can be deployed to multiple and different Kubernetes clusters providing the highest level of isolation. Further, Genus supports the deployment of multiple Genus applications into a single Kubernetes cluster separated by Kubernetes namespaces and standard Kubernetes Role-Based Access Control (RBAC).

Scalability is supported through standard Kubernetes mechanisms. Scalability can also be supported by standard features provided by cloud vendors, like the automatic scheduling of new nodes in Azure.

A failure in any Genus microservice will be detected through standard Kubernetes mechanisms and the microservice will be restarted by Kubernetes. The appropriate events will be logged and retrieved by any monitoring setup according to your choice.

Some cloud infrastructure providers also provide support for automatic node repair to automatically take measures when a node fails or becomes unresponsive.