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. Cloud Edition – hosted by us
  2. Enterprise / Team Edition – hosted by the client
  3. SDK Edition – integrated into customer’s solution

Cloud Edition

The hosted (shared) edition of Yarkon 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.

Enterprise or Team Edition

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)

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 16.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 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.

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
  • MSSQL

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

Please contact us to get the full details for this type of set up.

High-Performance

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.

SDK Edition

The following schema describes a common use of the Yarkon SDK, hosted by a web application.

This web application is responsible for the authentication phase. When the Yarkon web control is rendered, it will make an outbound call to get its AWS API keys. Using the user session data, the host application should be able to provide the keys corresponding to this user’s account permissions. Yarkon will follow up with another call to get the list of buckets allowed for this user.