Vision Docs

Vision App Maker scales by running more instances of its containerized components behind load balancers. Hardware sizing depends on the number of users, the volume of requests and documents, and the security requirements.

Scaling the components

The App Maker Engine, the API Gateway and the front-end clients can be replicated. The number of replicas is not limited by the platform. Each project sets the number according to its load-balancing and redundancy scenario.

Scaling runs on OKD or OpenShift, and Kubernetes is also supported. Supported orchestrators are Kubernetes 1.25+, OpenShift 4.x, OKD 4.16+ (recommended) and Docker Swarm. The orchestrator provides:

• load balancing through an ingress controller or a service mesh;
• auto-scaling based on traffic and load (CPU and memory);
• rolling deployments;
• failover and high-availability policies.

Every component of the system can run in high-availability mode. A high-availability cluster needs at least two worker nodes and one control plane node.

Load handling in the platform

Several platform mechanisms reduce load on the back-end services.

• API Gateway: routes requests with load balancing, aggregates responses from several services into one, caches responses, and applies rate limiting and throttling.
• Distributed cache: a distributed cache based on Redis, shared by the platform's replicas.
• gRPC between services: compact binary messages, multiplexing and low latency, with lower network and CPU use than JSON-based calls.
• Front-end: lazy loading of components and routes, code splitting, data caching and virtualization of large lists.
• Concurrent users: administrators can cap the number of simultaneous users. Above the cap, users wait in a queue, and administrators can follow active users, queued users and capacity.

Deployment topology

The recommended topology uses Docker containers orchestrated by Kubernetes, OpenShift, Docker Swarm or an equivalent. For on-premises high availability, the reference design uses:

• App Maker servers in network load-balancing clusters, each behind a virtual IP address;
• a SQL Server failover cluster on a storage area network;
• a reverse proxy and load balancer in the DMZ for external traffic.

The topology can be adjusted to the customer's needs, network and security. For more than 400 users, custom infrastructure topologies are proposed.

Technology stack

Server sizing

The table gives the recommended hardware for a database server and a web and application server.

Container infrastructure sizing

For an installation on containers and orchestration, the minimum hardware resources are:

These resources scale with the number of components and the volume of traffic.