Application guidelines

This page lists a number of guidelines that should be followed when developing a new application for the platform.

• Applications must be delivered as Docker Images
• Use semantic versioning.
• All configuration should be done through environment variables. At least everything that differ from test to production environment should be set as environment variables. Some examples:
  • Database username and password
  • Endpoints for other services
  • Log level
  • Database URL
  • Other properties that may differ between test and production environment.
• For centralized log collection to work logging must be done to stdout. Logs must not contain sensitive information. The format should be JSON.
• To correlate logs a common id should be used in all log statements. For a service receiving HTTP traffic the platform is generating the correlation id for you, if it is not already present in the request. The correlation id is available in the HTTP-header ‘X-Request-Id’. If the service is calling other services it should also set this header on the outgoing call. This enables correlation of logs between services.
• To make it easier to search for logs that should be correlated it is good practice to log the correlation id in a field called request_id.
• The service should expose a health url that returns HTTP 200 when the service is healthy and ready to serve requests.
• The service should expose metric url that can be scraped by Prometheus. Format can be found at https://prometheus.io/docs/concepts/data_model/.
  • The metrics should at least expose the number of total calls as well as failed calls.
  • It is good practice to expose an application_information metric with a label telling the version of the application. The value of the metric should indicate if the service is healthy. The value 1 (one) indicates that the searvice is healthy and 0 (zero) indicates that the service is unhealthy.
• As part of the configuration, in Git, CPU and memory requirements must be specified. The service will then be guaranteed that amount of CPU and memory.
• An application should be stateless. All states should be stored in an external datastore like MariaDB. Session stickiness is not supported.
• Backup interval and retention must be handled by the application supplier, either through the platform or in the application.