Preparation

This article covers the preparation phase of the platform that host iObeya, including how to estimate the sizing of the platform and the hardware configuration of the servers.

Global architecture

The following schema describes the global architecture of iObeya:

Security

The diagram below shows how our AWS platforms are set-up from a security perspective, in case you want to replicate an equivalent architecture on a private AWS cloud:

• Our platforms are hosted on AWS, utilizing various AWS security groups to ensure robust protection and access control.

• ELB + WAF: Traffic from users or machines is routed through the Elastic Load Balancer (ELB) with an integrated Web Application Firewall (WAF) to filter and protect against malicious activities. Only HTTPS traffic is allowed through port 443, ensuring encrypted communication.

• Admins access the environment through a bastion host configured for SSH access. Only SSH traffic is allowed through port 22 for secure administrative access.

• Confidential document, do not distribute, do not print / Copyright ⓒ iObeya 2024 6

• VPN Production Dedicated EC2 instances allocated per customer, ensuring isolated environments for each customer. These instances accept HTTP traffic on port 80 and SSH traffic on port 22 for management purposes.

• Each customer has also a dedicated RDS MySQL instance to ensure data isolation and security Only MySQL traffic is allowed through port 3306, ensuring database access is restricted and secure

• Our architecture employs a layered security model, incorporating multiple security groups and dedicated resources per customer to provide a secure and isolated environment for our SaaS offerings.

Platform scaling

Scaling

In the current generation (4.x), iObeya can only be scaled "vertically’”, i.e. by raising the raw power, CPU or memory or both, of the servers.

Warning:

It is not possible to scale by adding more servers, in an “horizontal” manner.

Therefore, we have organized the scale in the form of different packages for different combinations of users and rooms.

Packages

Each package is characterized by the number of active users, which is the most determinant scaling factor.

The figures that we have selected in the following table come from our own experience with different sets of platforms and sizes ranging from pack 1 to pack 10, that we use for estimating the scale of our client platforms. The package is chosen based on the estimated value of active users.

The other values are given as a typical indication on the platform usage in terms of users and rooms, depending on the number of active users.

Depending on the projections of active users for your own platform, you will then select the corresponding pack from the list below:

The following sections provide the values of parameters that must be adjusted depending on the pack that has been chosen. When the usage of your platform grows over the numbers of the initial package selected, you need to scale the configuration up to the next package level.

Hardware Configuration

The architecture is based on separate Application and Database servers whose configurations are listed in the next section. We do not specify the type of processor as this is not the most determinant factor, as long as the VM runs on a modern processor with a decent clock speed.

Hardware configuration table

The table below list the CPU & RAM configurations for both the application and database server for the different packs: