Add orchestration cluster glossary terms

[akeller]

Description

This is a DRAFT because a crisp definition is not found internally. This PR will need to be nurtured by an @camunda/tech-writers to work with @felix-mueller(?) on a definition.

We should also mention the 1:many relationship between a management cluster Web Modeler + Console and an orchestration cluster in SM, but I wasn't sure if we wanted to do that here when the definition should be crisp with a link to more info.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

[github-actions]

👋 🤖 🤔 Hello, @akeller! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.6/.

• docs/reference/glossary.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[theburi]

Orchestration cluster= Orchestration Cluster Core + Connectors+ Connectors Runtime
Orchestration Cluster Core = Zeebe, Operate, Tasklist, Optimize and identity

[akeller]

I added both terms, but referred to the "Orchestration Cluster Core" as follows:

Orchestration core

An orchestration core or orchestration cluster core includes Zeebe, Operate, Tasklist, Optimize, and Identity.

Would this work @theburi? Or do you want use to be specific and refer to this as "orchestration cluster core"?

[akeller]

@theburi I followed up on your doc since it sounds like some of this has changed while I was out. See my comments, particularly regarding SaaS and "core".

[akeller]

@theburi can you review these terms for good working definitions? We can refine them in another PR, but I want to make sure the tech writers know how to use these moving forward.

[conceptualshark]

This matches my understanding of orchestration cluster vs core, with two comments:

• As far as I understand, the Core will not change, but additional features might be added to the orchestration cluster - IDP and RPA? So the definition as written will need to be expanded when that occurs. I'm wondering if we have a more generic way to refer to "The orchestration core and any other optional components"?
• From what I've seen in discussions and PRs, we're using "orchestration cluster" over "core" almost exclusively. Is "core" something we want to push externally? Does it matter to a customer if they know "core" is only X components, or can they just assume their orchestration cluster is always X components, and also inclusive of anything else added to it? If we rarely use "core" in the docs it can make the communication a little more confusing. More of a question for @theburi.

[conceptualshark]

Based on further discussion with @theburi, going ahead and approving this, as it matches what was confirmed as approved in this internal doc.

We'll just need to remember that if/when additional features get added to the orchestration cluster, they will need to be added to this list.