qibb is available as SaaS on qibb-hosted infrastructure, with both multi-tenant and single-tenant options, or as PaaS deployed within the customer’s own infrastructure.
The qibb platform is designed as a fully cloud-native platform running on top of Kubernetes, the industry standard for container orchestration.
qibb is based on a microservice architecture, which is characterized by lightweight, container-based services. All services of the platform are optimized for the deployment on a distributed infrastructure and efficient use of system resources with the help of container virtualization. For example, a high resource utilization can be achieved by densely placing several containers on a node and thus minimizing idle processes. The platform and its workload can be rolled out and operated across several clusters, which in turn consist of several distributed cloud compute instances.
Multi-cluster architecture
ULTIMATE
The qibb platform can run and manage its workload across multiple clusters, which can be set up on different sites, locations or infrastructure environments. This allows site-specific requirements to be implemented.
What is a cluster?
A cluster is a group of distributed nodes. It combines their computing power, memory & storage to one entity.
For public cloud, we support the deployment on top of managed Kubernetes Services on AWS EKS. For on-premises, we support the deployment of qibb into Kubernetes environments running on VMware vSphere, such as provisioned and managed by Rancher RKE.
Multiple clusters can be used to distribute qibb environments across AWS regions and to provide stronger isolation between workloads.
Note: Workloads remain bound to the cluster and AWS region in which they are deployed.
For example, services such as qibb flows can be deployed to clusters in specific AWS regions based on availability, latency, compliance, or operational requirements. Typical scenarios include:
-
Multi-region coverage by operating qibb clusters in multiple AWS regions, giving you the flexibility to choose the most suitable region (via the the assigned qibb space) for each new app based on factors such as proximity, compliance, or operational requirements. Apps remain bound to the cluster and AWS region in which they are deployed.
-
Environment separation for development, staging, and production.
-
Client separation using dedicated clusters for individual customers or tenants.
-
Organizational separation across teams, business units, or responsibilities.
Operating multiple clusters also improves isolation and resilience by:
-
Limiting the failure radius of infrastructure incidents.
-
Supporting independent infrastructure lifecycles.
-
Separating workloads based on security requirements or data sensitivity.
Learn more about app deployments via qibb
Multi-cluster communication
Network connectivity must be ensured with suitable firewall rules to allow ingress and egress traffic between qibb clusters as well as for any communication between qibb workflows and connected third-party services.
The qibb platform distinguishes between different cluster types, which are based on their purpose and the services they contain. In addition, the respective clusters may have different features depending on their use case, such as different instance types or number of cloud compute instances.
|
Main Cluster |
App Cluster |
|---|---|
|
The Main Cluster of qibb represents the control plane of the platform. This cluster hosts the core components of qibb, which are responsible for the central management of all identities, deployed flows and connected clusters. Depending on the active user base and the number of attached clusters, the main cluster may require more or less resources to manage them. The cluster can be dynamically resized on-demand depending on the usage. |
The App Cluster is designed for running workloads (e.g., qibb flows). It serves as a base area for the creation of spaces and the rollout of application flows. For this purpose, it has an independent gateway to process network data streams independently of the Main Cluster. In addition, this cluster type hosts independent services for monitoring, which collect logs and metrics from local workload and forward them to external monitoring services. |
Learn more about qibb clusters
Resilience
Each microservice is responsible for a specific application domain or task and has minimal dependencies on other services, providing fault containment through isolated and independent components.
Critical services can be rolled out redundantly. Different rollout methods are supported:
-
Distributed rollout across multiple cloud compute instances, which ensures continued operation in the event of a node failure.
-
Distributed rollout across multiple zones in the public cloud or multiple data centers on-premise, which ensures continued operation in the event of a zone failure.
-
Optimized rollout of databases with sharding and replication.
Failure of partial components (containers) as well as complete cloud compute instances is automatically detected and compensated by the container orchestrator. Recovery can take place within a very short time and is fully automated. Typically, a failed container can be restored within seconds, a failed node within minutes.