It's not necessarily much in the way of extra steps. The Elasticsearch Cloud-on-K8s operator IMO does this quite well.
You define 'node sets' which each play a role in the cluster. Node sets can have tags applied to them, and this affects the procedures they run.
For example, you could say:
1. Let's have a node set of 3 master nodes.
2. Let's have a nodeset of 10 hot data nodes, backed with SSDs and tagged with 'hot'.
3. Let's have a nodeset of 5 cold data nodes, backed with HDDs and tagged with 'cold'.
4. 4 client nodes for load balancing.
You could also say - let's have 3 nodes that play all roles.
On startup, each node starts only the parts of the app that correspond to the roles it's playing.
It's fairly seamless and I think this model would expand quite nicely to 'business logic' services
Anecdotally, have seem some people attempt to retrofit a poor man's version of this model into their microservice in response to e.g. performance problems.
Comments
It's not necessarily much in the way of extra steps. The Elasticsearch Cloud-on-K8s operator IMO does this quite well.
You define 'node sets' which each play a role in the cluster. Node sets can have tags applied to them, and this affects the procedures they run.
For example, you could say:
1. Let's have a node set of 3 master nodes. 2. Let's have a nodeset of 10 hot data nodes, backed with SSDs and tagged with 'hot'. 3. Let's have a nodeset of 5 cold data nodes, backed with HDDs and tagged with 'cold'. 4. 4 client nodes for load balancing.
You could also say - let's have 3 nodes that play all roles.
On startup, each node starts only the parts of the app that correspond to the roles it's playing.
It's fairly seamless and I think this model would expand quite nicely to 'business logic' services
Anecdotally, have seem some people attempt to retrofit a poor man's version of this model into their microservice in response to e.g. performance problems.