Vision Docs

Vision App Maker runs as containerized components orchestrated by Kubernetes, OpenShift, OKD, Docker Swarm or an equivalent. It can be installed on-premises, in a public cloud (AWS, Azure, Google Cloud) or in a hybrid setup.

Deployment model

The platform is designed for public or private clouds. Its components run as decoupled logical services in containers, based on microservices, APIs and micro-segmented communication. The environment is fully virtualized.

The containerized components are:

• the front-end web clients: internal portal, external portal and info kiosk;
• the API Gateway (App Maker Gateway);
• the processing engine (App Maker Engine);
• the administration and configuration component (App Factory Studio);
• a distributed cache based on Redis, shared by the platform's replicas;
• auxiliary services such as authentication, file processing and external integrations, depending on the configuration required.

The containers follow the Open Container Initiative (OCI) and Docker standards. The platform is compatible with Platform-as-a-Service offerings that build, deploy and scale containerized applications.

Supported orchestration

Each project defines its own topology. The topology sets the component types and how they are installed, load-balanced and made available.

High-availability topology

The reference topology separates the internet-facing zone from the internal network. It can be adjusted to the customer's network and security setup.

• External clients reach the platform from the internet through a firewall.
• A reverse proxy and load balancer in the DMZ receives external traffic. It forwards portal requests to a load-balanced application cluster and API and content requests to the internal address.
• App Maker servers run in network load-balancing clusters, in pairs, each pair behind a virtual IP address.
• Internal users reach the internal portal through its own virtual IP address.
• The databases run on a SQL Server failover cluster of two nodes, on a storage area network.
• A second firewall separates the DMZ from the internal network.

Components with external access can be placed in the DMZ. They communicate with internal components only over HTTPS, through the reverse proxy. The external portal never accesses the database directly.

Prerequisites

The prerequisites below are a summary. Exact versions and installation steps are provided with the installation manual.

Infrastructure

• On-premises, cloud (AWS, Azure, Google Cloud) or hybrid infrastructure.
• Linux-based operating system: Ubuntu, Red Hat Enterprise Linux, CentOS Stream or Debian.
• TCP/IP connectivity between nodes and access to a container registry.
• A dedicated DNS subdomain and valid TLS/SSL certificates for exposed components.

Software

• Docker Engine and an orchestrator (Kubernetes, OpenShift, OKD or Docker Swarm).
• An ingress controller for load balancing, such as NGINX Ingress, Traefik or HAProxy.
• A container registry, such as Docker Hub, Nexus, Harbor or GitLab Registry.
• .NET Core runtime, Node.js for the front-end build and Microsoft SQL Server.
• Optional: Helm for chart management, and Kafka or RabbitMQ for event processing.

Security

• Integration with the existing authentication system: LDAP, Active Directory, OAuth2 or Keycloak.
• Firewall policies for the required ports and network isolation through network policies.
• Role-based access control in the Kubernetes cluster.
• Optional container image scanning, for example with Trivy or Clair.

Network and load balancing

• An external load balancer: NGINX, HAProxy or a cloud load balancer.
• HTTP and HTTPS traffic on ports 80 and 443.
• For high availability: at least two worker nodes and one control plane node.

Storage and backup

• Persistent storage, such as NFS, Ceph or EBS volumes, for files the applications need, for example the electronic seal used for signing.
• Defined backup policies for databases, generated files and configurations.
• Sensitive settings and connection strings can be stored as orchestrator secrets.