Platform Management
Know everything about Artifakt platforms and how to set the right infrastructure sizing for your applications' needs.
Platform example
Depending of your needs and the criticality of your web applications, Artifakt offers two types of platform: Starter and Scalable.
We recommend that you take some time before choosing the platform type as it is currently not possible to switch from one type to another within the same environment. It means, if you want to switch from a Starter to a Scalable platform, you will have to create another environment and then destroy the old one.
Starter platforms are best suited for development environments, simple websites or small web projects. They are made up of 1 instance hosting your web application and all your additional services such as MySQL, Redis, etc.
Starter platforms are not scalable and not resilient. Changing Starter platform sizing (vertical scaling only) will lead to downtime. In addition, the instance type is burstable, which means that the performance is not stable over time.
Scalable platforms are the go-to standard for the most critical apps (global availability, requiring high resiliency and efficient scalability). They are made up of at least 2 instances allowing resiliency in case of an outage (failover mechanism) for web applications and additional services (critical mode only).
- Databases have three (3) nodes in total.
- The other additionnal services have two (2) nodes.
Using Scalable platforms, you will be able to manually scale horizontally and vertically, while avoiding downtime. You will also be able to define rules to automatically scale horizontally, based on memory or CPU usage.
The Scalable platforms are highly available:
- Compute: Scalable platforms benefits from load balancing, auto-scaling and provisioning across a maximum of 3 different geographical zones within a Region. When deploying an instance, it will deploy automatically on the least used zone, or a random one if there is no least used zone, ensuring maximum availability. The instances are all load balanced and work in an active/active mode.
- Additionnal services: we automatically deploy services with one standby replica in a different zone. They function in the Active/Passive mode, and a failover happens automatically when the Active component is failing.
- Storage: we automatically store all data across different zones in an active/passive mode.
By locating cloud resources in different zones, we eliminate the chance that a failure such as a power outage, fire or flood in one zone will cause a component and therefore your website to fail.
One of the specificities of the Scalable Platform is the presence of a file system mounted on all front servers. It is akin to a standard Network File System (NFS) share, but has a few unique features :
- The Elastic Storage grows as you include more files into it so you will never effectively run out of space.
- The Elastic Storage gets faster as it gets larger.
Please note that you get charged for your Elastic Storage usage. Adding more files will increase your usage and you will be charged accordingly.
Go to Environment → Settings → Resources to manage the sizing of your platforms resources. From this page, you can easily define application resources, additional services, replica limits (scalable type only) or auto scaling configuration.
Modifying application resources
This section allows you to scale up or down memory (RAM) and storage, based on your web application's needs. If you experience slowness or timeouts, consider increasing the memory.
Please note that
- The application storage is only used for your source code and the Operating System (OS) of the instance.
- The application storage is ephemeral (data will be lost if servers are replaced or terminated). Please add a persistent disk to store your media and assets.
- The application storage cannot be decreased when an environment is
Online(data protection policy) - The application instances (web replicas) are not meant to be used as emails servers (Port 25 is disabled by default). Please use third parties or additional services to send your transactional emails.
- If you are using Starter platform, you should stop manually your instance before applying new compute or storage sizing. Updating sizing on starter platform will not remove or replace the instance or your data stored on it.
- If you are using Scalable platform, sizing updates will create new instances with the new sizing, move the web traffic to these new instances, then remove the old instances. All this process help you resize your platform without any downtime.
This section allows you to configure sizing of your additional services such as persistent disk, MySQL, etc. More details about additional services here.
replica limit configuration
This section lets you configure the number of replicas that will support your platform. Depending on the platform type, you will be able to configure the minimum and the maximum number of replcias.
The difference between the maximum and minimum number of replicas relates to the number of load replicas available for your platform (used by auto-scaling). These replicas will turn on or off depending on the environment's usage (Scalable platforms only).
Please find below some information about replica limits.
Platform type | Minimum number of replicas | Maximum number of replicas |
|---|---|---|
Starter | 1 | 1 |
Scalable ( noncritical) | From 1 to 10 | From 1 to 10 |
Scalable ( critical) | From 2 to 10 | From 2 to 10 |
Updating auto scaling configuration
The auto-scaling feature is only available for Scalable platforms.
This feature allows you to define rules (RAM or CPU usage thresholds) that will be used to respond to traffic drops or peaks according to your needs.
For example, for traffic peaks, you can set the CPU usage threshold to 70% for 5 minutes. It means that if the average CPU usage of all servers is above 70% for more than 5 minutes, a new server will be automatically started to process new web requests (if the maximum number of servers defined has not already been reached).
At any time, you can change the platform sizing and configuration. If the environment is
unbuilt, the settings will be saved in Artifakt, in order to be used the next time you start the environment. If the environment is built, Artifakt will trigger a new version to be approved and will keep an history of all the previous versions.After saving platform settings, a message will display at the top of the page to notify you that changes need to be applied. You can also see when and by whom these changes have been made.
For security purposes, approving changes is limited to users with Admin role.
Reviewing platform changes
By clicking on the link Uncommitted changes need to be reviewed, you can review all changes made on the platform. After reviewing, if the changes are satisfactory you can approve them; otherwise if you realize the changes are incorrect you can reject them which will cancel the platform update.
To help you understand the process, here is how the update of any platform works at Artifakt:
Platform update workflow
Please note that, after approval, your changes will apply within a few minutes and downtime may occur in order to update the platform.
Each time you update the settings of a platform and approve the changes, we increment the version of that platform by one. For example, at some point, your environment will use version 12 of your platform (because you've changed it 12 times).
Platform history page
We have added a platform version history page accessible from Environment → Settings → Platform → Platform History. It helps you keep track of configuration changes made on your platform and know exactly what has been changed, when and by whom.
Last modified 6mo ago