1. Introduction

To guarantee high software quality and to ensure that CaaS Platform runs in all supported configurations, regular tests are carried out within the scope of quality assurance. Reference configurations are used to perform these quality tests. In a real scenario, however, usually certain deviations from the reference configurations will exist.

In order to provide planning security for a company introducing new software for this case as well, a more extensive number of system configurations are defined as actively supported. But, unlike the reference configurations, not all actively supported system configurations are tested regularly for functionality. However, Crownpeak Technology GmbH assures that if problems occur with a configuration defined as being actively supported, measures will be taken to solve them.

In addition, there is a range of passively supported system configurations. These are not actively tested by Crownpeak Technology GmbH, but are successfully in use by our customers or partners or were supported in previous versions.

In a few cases, incompatibilities with certain system configurations have been noticed. These system configurations are defined as not supported.

This Technical Data Sheet is valid for CaaS Platform Version 2.0 and above.

2. Terminology

As mentioned in the introduction, real life systems will often not match the reference configurations, which is why a distinction between active/passive supported and unsupported configurations is necessary. Therefore the following terminology is used in this document.

Reference

To ensure that incompatibilities are detected prior to delivery, CaaS is regularly tested with this configuration, for which no restrictions are imposed. Furthermore, if necessary, mechanisms which avoid occurring errors in third party products and, thus, prevent problems during interaction with CaaS will be integrated into CaaS for reference system configurations.

Actively supported

This (or a very similar) system configuration has been tested by Crownpeak Technology GmbH and assessed as being functional. However, due to the time required, the relevant tests are carried out regularly but cannot be performed completely with each release (unlike Reference). We maintain the necessary infrastructure in-house, so that we can quickly carry out our own tests and if necessary debugging.

Prerequisites for the elimination of errors are:

  • Reproducibility of the problem

  • Current maintenance contract

    If error elimination is not possible (e.g. for technical reasons), the system configuration will be defined as Not supported in the next version of the Technical Data Sheet.
Passively supported

This (or a similar) system configuration is or has been successfully operated by a customer/partner and reported as being functional; however, this statement has not been checked by Crownpeak Technology GmbH. In general, a corresponding system configuration does not exist at Crownpeak Technology GmbH, so internal tests are not possible. Crownpeak Technology GmbH can take debugging steps on the basis of error messages (if a current software maintenance agreement exists); however, only within a limited time frame – but the customer has no claim to this.

Especially within the scope of the further development of CaaS, new product functions can result in system configurations that were previously passively supported being declared explicitly not supported, although an adjustment of CaaS to the passively supported system configuration would be technically feasible.

Not supported

The system configurations listed are known to lead to problems or are highly likely to cause problems. Crownpeak Technology GmbH will not take measures to eliminate possibly occurring problems. If a system configuration is not listed here, it does not mean that it is supported, but only that there is no specific information at present.

3. System requirements

This chapter describes the system configurations CaaS Platform is able to run with.

Kubernetes as well supports various platforms, although the manufacturer does not get explicit about them. Besides many as-a-service offerings and hosted environments, Kubernetes can be installed from scratch as well.

Kubernetes supports various operating systems and is supported by many service providers.

Detailed information can be found in the official Kubernetes Documentation.

ACTIVELY SUPPORTED

  • Kubernetes version 1.19.6

  • Helm 3

This is the reference system configuration that is regularly used and tested by Crownpeak Technology GmbH.

PASSIVELY SUPPORTED

  • Kubernetes version >=1.19.0

NOT SUPPORTED

  • Kubernetes version <1.19.0

  • Helm 2

4. Recommended hardware configurations

The following configurations are determined by extensive load and stress test scenarios we ran. Since we simulated test runs with virtually up to 100.000 users doing different operations, the following configurations are likely to be sufficient for a production scenario. The Kubernetes stack is well-prepared for scaling in different ways.

According to the default configuration a Kubernetes setup must be configured with at least three mongodb pods. Each of these pods requires storage amounting to at least 5 times the deployed size of the Project. On top of that the mongodb also keeps a journal of transactions in storage. This can take up varying amounts of space depending on the number of concurrent write requests. Note that this is independent of project size but instead depends on the current workload. In a project of 500MB, journal sizes varying between 300MB and 1500MB have been observed. If a mongodb instance runs out of storage space it will crash. This can result in severe instabilities in the Kubernetes cluster.

Write requests pass through the single primary node of a mongodb cluster. For this reason, it is necessary to react to high load requirements due to writing scenarios with vertical scaling of the nodes used.

Scenarios of many read operations are expected to be most likely. With a single REST API instance, configured with 250 millicores and 350MB memory limit, an Amazon EC2 t2.medium instance is capable of processing 350 requests of mixed nature per second with a response time of less than 200 ms for 99% of all requests.

The mean time for a request is only 21ms. The amount of requests the stack can handle is linear to the number of REST API instances running until the database cluster becomes your limiting factor.

5. Support for on-premises installations

Technical support is typically focused on resolving issues related to the product itself, such as software bugs or compatibility issues. Customer-specific operating problems usually fall outside the scope of technical support, as they may require troubleshooting and guidance specific to the individual’s unique setup or circumstances.

When contacting Technical Support with a bug report, a detailed description of the problem as well as logs indicating the problem and reproduction instructions are required.

We recommend installing regular updates for our product in order to minimize the risk of problems occurring.

6. Help

The Technical Support of the Crownpeak Technology GmbH provides expert technical support covering any topic related to the FirstSpirit™ product. You can get and find more help concerning relevant topics in our community.

7. Disclaimer

This document is provided for information purposes only. Crownpeak Technology GmbH may change the contents hereof without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Crownpeak Technology GmbH specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionality, services, and processes described herein are subject to change without notice.