Scaling and middleware roles

Any of the middleware pods can have any combination of these roles:

• documents
• http-api
• sync
• admin
• businessmobility (please note that this feature is only available in the appsuite-pro-sync image or a customer-specific one if part of the contract)

You can specify how many pods for any combination of these roles you want in your cluster. Let's look at a few examples:

core-mw:
  scaling:
    nodes:
      groupware:
        replicas: 3
        roles:
          - http-api
          - sync
          - documents
      admin:
        replicas: 1
        roles:
          - admin
      eas:
        replicas: 1
        roles:
          - businessmobility

This gives us five pods, 1 reserved for provisioning (admin), 1 for EAS and 3 for the rest of the functions. What does it mean to be reserved for a task? The helm chart sets up services for the roles and puts every pod that is supposed to serve that role into one of those services:

So you can set up incoming traffic routing accordingly.

• DAV goes to the appsuite-core-mw-sync
• EAS goes to appsuite-core-mw-businessmobility
• HTTP-API traffic to appsuite-core-mw-http-api
• internal SOAP calls via different Gateway on a different Port go to appsuite-core-mw-admin.

We can also slice the cake differently, with, say specialised pods for all tasks:

core-mw:
  scaling:
    nodes:
      documents:
        replicas: 3
        roles:
          - documents
      http-api:
        replicas: 4
        roles:
          - http-api
      sync:
        replicas: 2
        roles:
          - sync
          - businessmobility
      admin:
        replicas: 1
        roles:
          - admin

This gives us a cluster of

• 3 pods for documents,
• 4 HTTP-API pods,
• 2 Sync/EAS pods and,
• 1 provisioning pod.

Routing is still the same as above, since the pods will be added to the services matching the roles they have. If we don't want a separate sync cluster, we can consolidate them back into the http-api nodes:

core-mw:
  scaling:
    nodes:
      documents:
        replicas: 3
        roles:
          - documents
      http-api-and-sync:
        replicas: 4
        roles:
          - http-api
          - sync
          - businessmobility
      admin:
        replicas: 1
        roles:
          - admin

Etc. The point is, we can scale individual roles independently of each other and also figure out