Application (WaaS)
      Back to home
      1. Documentation
      2. Application (WaaS)

      Managing the Application Configuration

      The application configuration allows you to tailor the quantity and quality of the computational resources that serve the tenants within an application.

      Not all websites are built equal. With a different array of requirements we try to have an understandable yet comprehensive offering of scaling and container configurations that fits your use case as best as possible.

      In this article we will look at the following subjects:

      What is a Container?

      Every tenant or website on wildcloud runs in a container. A container is a lightweight, standalone, and executable package that includes everything needed to run a piece of software, including the code, runtime, libraries, and system tools. These containers act like what on a traditional hosting solution would be a VM, but they are rather different.

      The main difference is that creating a new VM and configuring this to run a site can be quite a hustle. Setting up a new server is even more work. Containers however can be easily run everywhere due to their pre-packaged nature and portability to almost every system. 

      Where VMs or servers are bulky and static, containers are lightweight and can be handled much more dynamic. The qualities of a server in terms of CPU and RAM are usually set in stone, at least as long as you're not able to add some more RAM in the physical machine. VMs are a bit more easy to change, but are usually bulky, not optimized and thus require a lengthy restart to change. Containers, because of their specialization and focus on minimizing overhead are easily created and destroyed.

      The Application Configuration can be accessed by clicking "Configuration" when you're in a specific application.

      Container configuration

      The container configuration determines the CPU and memory that is available to the containers serving the tenants of an application. It therefore determines the quality of the containers that serve the tenants within the application. 

      Because containers are dynamic, if these values need to be changed we simply create a new container with the updated properties, schedule it to our cluster and remove the old containers. The cluster itself makes sure all the traffic is routed correctly and a rolling update together with health- and availability checks will ensure that there is zero downtime for serving the tenants.

      What container configuration should I pick?

      To determine the correct configuration it is good to start at what the tenants that are being served by these containers need.

      When the tenants being served are mostly portfolio sites, or consist of simple pages with little to no complexity then using a Small container usually works fine.

      When the sites become more complex, think about e-commerce, or when the sites run on themes and editors that require more memory when your customer is editing their site, it is good to take at least a General purpose container.

      Certain applications, such as larger e-commerce applications, learning management systems or sites that combine various of such tools, will need more memory and CPU to properly function. For those applications we usually advise a Heavy duty container to ensure availability.

      There are different types of tenants in my application, do they all need the same configuration?

      The sort answer to this is: yes. The slightly longer answer is that due to the multi-tenant nature of the wildcloud platform, it is currently not possible to have different configurations for different tenants. If the requirements for different tenants within the same application is wildly different, consider splitting up the application to be able to make use of different configurations.

      Scaling configuration

      There the two approaches to scaling your resources: absolute scaling and per tenant scaling. These configurations determine how the number of containers—each serving one or multiple tenants—is managed in response to fluctuating traffic and workload demands. The choice between these two methods hinges on the nature of your WaaS platform, the predictability of your traffic, and the growth trajectory of your tenant base.

      Absolute Scaling Configuration

      Absolute scaling involves setting a fixed minimum and maximum number of containers that will be available to serve all tenants on the platform. This method is straightforward and is often chosen when the collective resource needs of the tenants are predictable and relatively stable. It's ideal for WaaS platforms with a consistent performance requirement, where traffic peaks and valleys are well-known and can be planned for in advance.

      Per Tenant Scaling Configuration

      Per tenant scaling, on the other hand, ties the number of containers to the number of active tenants. This dynamic approach automatically adjusts the number of containers based on the total number of tenants, providing a ratio that defines how many containers are allocated per tenant. This configuration is particularly effective for WaaS platforms that experience organic growth or have tenants with varying levels of resource consumption.

      Both configurations offer the flexibility inherent to usage-based pricing, ensuring that you only pay for the resources you use. However, choosing the right scaling strategy can optimize performance during critical periods and help manage costs more efficiently.

      In Short:

      • Absolute Configuration: You set a fixed number of containers that will be used regardless of the number of tenants. This is simpler for predictable traffic patterns and when you have a clear understanding of the resource needs for all tenants combined.
      • Per Tenant Configuration: You specify a ratio of containers to tenants, which automatically adjusts the number of containers based on the total number of tenants. This model is more dynamic and scales with the growth of your tenant base, making it suitable for platforms with varying performance needs across different tenants.

      Example 1: Regional Business Directory WaaS

      Use Case: A company operates a regional business directory WaaS, hosting multiple tenants, each representing a local business. On a typical day, the directory receives a steady but manageable amount of traffic. However, during regional events or promotions, all businesses see a significant increase in visitor numbers.

      Configuration on an Absolute Level:

      • Minimum Containers: 2 (to adequately handle the regular traffic of all tenants combined)
      • Maximum Containers: 6 (to accommodate the surge in traffic during regional events)

      Cost Breakdown:

      • Minimum Containers Cost: If a General Purpose container costs $17 per month and is shared by all tenants, the baseline cost would be $34/month for the 2 containers.
      • Maximum Containers Cost: During regional events, if traffic requires scaling up to 6 containers, the additional cost would be $102 (4 extra containers x $68 each). This additional cost is only incurred on the hours when traffic peaks and requires scaling up.

      Configuration on a Per Tenant Level:

      • Minimum Containers Per Tenant: 0.1 (at least one container for every 10 tenants under normal conditions)
      • Maximum Containers Per Tenant: 0.5 (up to one container for every 2 tenants during peak times)

      Cost Breakdown:

      • Minimum Containers Cost: With 50 tenants and a cost of $17 per container, you would need 5 containers to meet the minimum (50 tenants x 0.1 containers per tenant), totalling $85/month.
      • Maximum Containers Cost: During peak times, if each tenant nearly requires half a container due to increased traffic, you'd need up to 25 containers (50 tenants x 0.5 containers per tenant), which would cost $425 (25 containers x $17 each) for those peak days.

      Example 2: Online Portfolio Platform WaaS

      Use Case: A creative agency offers an online portfolio platform as a WaaS to artists and designers. The platform typically has low traffic, which spikes when artists release new work or during industry events.

      Configuration on an Absolute Level:

      • Minimum Containers: 1 (to maintain service availability for all tenants during typical low traffic)
      • Maximum Containers: 4 (to handle traffic spikes when multiple tenants simultaneously have high traffic)

      Cost Breakdown:

      • Minimum Containers Cost: With a Small container costing $12 per month, the baseline cost would be $12/month.
      • Maximum Containers Cost: In times of high traffic, if 4 containers are needed, the cost would be $48 (4 containers x $12 each) for the duration of the spike.

      Configuration on a Per Tenant Level:

      • Minimum Containers Per Tenant: 0.05 (one container for every 20 tenants)
      • Maximum Containers Per Tenant: 0.25 (one container for every 4 tenants during high-traffic events)

      Cost Breakdown:

      • Minimum Containers Cost: For an instance with 80 tenants, you would require 4 containers to cover the minimum (80 tenants x 0.05 containers per tenant), resulting in a cost of $48/month.
      • Maximum Containers Cost: During peak industry events, if the traffic necessitates a quarter of a container per tenant, you would need 20 containers (80 tenants x 0.25 containers per tenant), costing $240 (20 containers x $12 each) for those specific periods.

      What if one tenant has a lot of traffic and others don't?

      While the assumption of our multi-tenant setup is that there shouldn't be a lot of differences between individual tenants, it can happen that there is a tenant that stands out. There are a few ways to deal with this.

      Firstly, increasing the scaling configuration to accommodate the one tenant is a solution. This will increase the overall usage costs associated with it, but this can either be smeared out over everyone, or skewed towards that one customer that is popular.

      Another option, although less preferred, is to move this tenant to another application or hosting solution all together. While this creates overhead in terms of maintenance and billing, it could very well be worth it if the scaling necessities for this one tenant become really skewed with regards to your average tenant.

      Backup frequency

      While slightly unrelated to the world of container, CPUs and scaling configurations, another thing that is managed on an application level is the backup frequency. Every tenant is backed up individually. These backups can be restored at any time and have a retention of 30 days. How often backups are made is part of the Application configuration.

      Cronjob frequency

      A lot of WordPress sites require tasks to be done every so often. Be it clearing a cache, sending out e-mails or checking up on orders. Most WordPress setups have a cronjob runner on the server, either as an actual Linux cronjob, or by using some external tool. While these do not directly interfere the user's requests, they do take up resources on the server. At wildcloud we separate the containers that serve tenants from the containers that run cronjobs.

      How often the cronjobs should run for every tenant is part of the Application configuration and is therefore the same for every tenant. When determining the frequency, the type of application and number of background processes should be taken into consideration. For tenants running our Storefront WaaS-Host plugin we recommend every minute. For portfolio sites that lack a contact form they could even be turned off.