Scaling and middleware roles

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

• hazelcast-data-holding or hazelcast-lite-member
• http-api
• sync
• admin

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
          - hazelcast-data-holding
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-data-holding

This gives us four pods, all hazelcast data holding nodes with 1 reserved for provisioning (admin) 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:

Role	Service
admin	appsuite-core-mw-admin
http-api	appsuite-core-mw-http-api
sync	appsuite-core-mw-sync

So you can set up incoming traffic routing accordingly.

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

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

core-mw:
  scaling:
    nodes:
      hazelcast:
        replicas: 3
        roles:
          - hazelcast-data-holding
      http-api:
        replicas: 4
        roles:
          - http-api
          - hazelcast-lite-member
      sync:
        replicas: 2
        roles:
          - sync
          - hazelcast-lite-member
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-lite-member

This gives us a cluster of

• 3 Hazelcast data holding pods that serve no traffic,
• 4 HTTP-API pods,
• 2 Sync 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:
      hazelcast:
        replicas: 3
        roles:
          - hazelcast-data-holding
      http-api-and-sync:
        replicas: 4
        roles:
          - http-api
          - sync
          - hazelcast-lite-member
      admin:
        replicas: 1
        roles:
          - admin
          - hazelcast-lite-member

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