More clarity what's recommended for local development

[akkie]

If we read through the documentation and also through the readme, it's currently not really clear what it's recommended for local development.

The documentation says as example, the recommended way for development is:

For development usage, we highly recommend using our Helm charts on KIND if SaaS provided by Camunda is not an option for you. Those Helm charts are battle-tested and give you an experience close to production.

1. SaaS
2. Helm charts on KIND or Helm on a managed Kubernetes offering (like GKE) or Helm on a local Kubernetes installation like minikube.
3. Docker Compose
4. Local installation

But is says also:

• Kubernetes: We strongly recommend using Kubernetes to run Camunda Platform 8 in production. Using minikube, Kubernetes can also be an interesting environment to run Camunda Platform 8 locally on developer machines.
• Docker: You can run the provided Docker images of the components, also in production. For your convenience, we provide a Docker Compose configuration to run Camunda Platform 8 on developer machines. Note that the Docker Compose configuration is not optimized for production usage, but for local development.

The readme of this repo says: ⚠️ Docker Compose is only recommended for local development. ⚠️

We recommend using SaaS or Helm/Kubernetes for development.

And in the docker compose file there is also a hint:

# For local development, we recommend using KIND instead of `docker-compose`:

# https://docs.camunda.io/docs/self-managed/platform-deployment/helm-kubernetes/guides/local-kubernetes-cluster/

We are currently writing documentation and a best practice recommendation for our developers and the discussion came up if docker compose or a local Kubernetes deployment is the preferred way. Especially if we look on the aspects of "battle-tested" and "experience close to production".

There is also the question of what exactly is meant by 'development' and 'local development'. My assumption was that:

• development: means the overall development process where you provide an installation for different development environments like: Dev, Test and Stage
• local development: installing the platform on a local machine or development VM

Is this correct?

[jessesimpson36]

Hello,

Sorry it took me a little while to actually see this message. You've definitely pointed out a vague area in our documentation! So I'll try to clear some things up for you in this comment.

The ideal way to develop the application is to use KIND with the helm chart. There are a number of developers internally that do not want to deal with kubernetes applications, and the added complexity that goes along with kubernetes applications. A developer for Zeebe may only want to run the docker compose deployment method with their Zeebe instance running from some IDE. However, if you're development involves the interaction between components, KIND and the helm chart may make sense.

As for this statement:

Those Helm charts are battle-tested and give you an experience close to production.

I would not place much emphasis on the phrase battle-tested. The Camunda Platform Helm Chart is our official way of deploying Camunda 8, and we have many customers using our helm chart in production. The helm chart is harder to configure though. For that reason, a customer may want to try out Camunda Platform in docker compose before putting in the effort necessary to configure the helm chart.

As for the difference between Development and Local Development, we do not have any unified language regarding this.

With this phrasing:

For development usage, we highly recommend using our Helm charts on KIND if SaaS provided by Camunda is not an option for you.

This usage of development refers to people creating BPMN workflows and deploying their workflows. Not the development regarding writing java code for the actual components such as Zeebe or Tasklist.

I hope this clears things up for you. I think we can leave this issue open if you have followup questions or so that we can triage it in with our other documentation-related issues.

[jessesimpson36]

Closing due to inactivity.