Yarkon System Architecture

Yarkon is available in several options, which define the architecture used. In the following you can find an overview of the system architecture commonly used, broken into these standard solutions:

  1. Yarkon Cloud - hosted by us
  2. Yarkon Server - hosted by the client

Yarkon Cloud

Yarkon Cloud Configuration

Yarkon Cloud is using a multi-tenant architecture, with the load spread across numerous servers in an auto-scaling group.

For increased performance, the client application is hosted in a CDN (AWS CloudFront).

A multi-zone RDS database is used to store the data, following all of Amazon’s best-practices for performance and security.

Yarkon Server

The Yarkon application is very flexible in the way it can be set up. In essence, the solution must deliver on the following:

  1. Serve HTML files to the end users.
  2. Allow the web client to communicate with the server.
  3. Have a server accessible by an Administrator for management tasks.

Below are a number of configurations that address the most common scenarios.

Basic (Minimal)

Basic Configuration

The most basic configuration only requires a single EC2 instance. It is, however, highly recommended to use a load balancer (ELB) in front of the server, so you can use an SSL certificate installed there and terminate SSL traffic at the load balancer. This approach reduces the load from the server and greatly simplifies the management of the certificates. It will also allow you to not expose the Yarkon Admin Console server to the outside world, thus reducing your security concerns. If you prefer to not use an ELB, you will have to install your SSL cert on the server itself. The procedure is standard to a Unix server (the AMI is based on an Ubuntu Server 18.04 LTS).

It is recommended to start with this configuration, and only upgrade to a more complex (and usually costlier) architecture in case of a performance issue or a critical business need.

High-Availability

To achieve the goal of high-availability, you will have to install at least two instances, in different availability zones.

High-Availability Configuration

In this case, a load balancer (ELB) is required. A shared database is also required, so this configuration will need access to an SQL based database. The standard configuration we use is using MySQL, but it should work just as well with other RDBMs. Currently supported are:

  • PostgreSQL
  • MySQL
  • MariaDB
  • SQLite

You can use an AWS RDS based database, or any other stand-alone database server.

Check out this document to get the full details for this type of set up.

High-Performance

High-Performance Configuration

The next step after high-availability is high-performance. Only take this step if you are sure any performance related issue is due to the load on the servers, and you confirmed that adding a server will not solve the issue.

Using a Content Delivery Network (such as AWS CloudFront) will give your end users improved download time when they open the application in a browser.

A minor change to the server setup is required. Please contact us to get the full details for this type of set up.

VPC Endpoints (Proxy)

v4.1.0

VPC Endpoints Configuration

When using VPC endpoints buckets, you can use Yarkon Server as an in-VPC proxy allowing your end users secure access to the buckets, without opening your buckets to outside of VPC access. To turn this feature on, go to the Provider tab under Administration, and check the Proxy box.

This configuration can be used together with any of the other configurations. The image shows it used together with the basic configuration.