@kthoms put in a lot of work to make the “run” distribution work again. It is now built in the nightly build and can be run without setting up any code in the project. It’s great to have that option again, thanks a lot!
In the ticket, the question arose if we wanted to put “Operaton Run” in the startup banner or just “Operaton”, and this led to the question if “Operaton Run” was even the best choice for a name, or if it was too close to the upstream projects naming.
I can think of several pro and contra arguments. E.g. “Camunda Run” was never really expressive in the first place, on the other hand most users coming from Camunda would immediately know what to expect behind the name.
What do you think, I would love to read some more opinions on this.
Some alternative ideas I came up with off the top of my head:
Operaton Standalone (does not carry the “local dev only” aspect)
Operaton Playground (might sond not serious enough)
Operaton Sandbox (also not serious, also sounds like it would contain something and prevent it from breaking out into the system)
I must say that in every presentation i had, i always had to explain that Run was the standalone version… so maybe “standalone” itself would be a better name than run and will explain it early
But i never really used, as i always used my engine in spring project since the starter was created in 2018/2018, so my “standalone” info can be wrong
The “Camunda Run” distribution is meant as a package to get started quickly with a standalone architecture. I have used it in trainings in the past. It is a Spring Boot setup, preconfigured with the web apps which can be started on Windows, Linux and MacOS with a shell script. It has folders provided in which you can drop the jars for cockpit engine plugins, without needing much Java Knowledge
Ok. Now we have to decide whether the name should reflect what it is or whether it should be just a catchy name that’s easy to pronounce and to recall.
For the first type, it could be “Operaton EET” (or just "ET) for “engine for external tasks”. Or “ETS” for “external tasks server”.
For the second type “Op. Run” or “Op. Now” would be ok. “Run” has the advantage of being similar to Camunda and familiar to its users.
“Standalone” is kind of suitable, but also sounds a bit old-fashioned. I have no strong opinion on it, and like it more than other alternatives.
The “ETS” version sounds “enterprisy” to me, I kind of like it, but am not sure if it is fully matching the use case. Does it really “serve” external tasks? It more interacts with them, so maybe even the opposite?
Yes why not, Operaton without the suffix is the “standalone” distribution, vs. Operaton embedded (or specifically Wildfly/Spring/Quarkus/etc) which is the embedded version
If I think of a Download page, this would mean we have:
Operaton Wildfly Distribution
Operaton Tomcat Distribution
Operaton
This would imply that the “Operaton” one is the default one, the product you should use if you don’t need Tomcat or Wildfly. This argument could be made, as Camunda always stated that Run is production ready and preconfigured. We would name the Docker images in the same pattern, meaning that operaton/operaton is the default you should use if you need an Operaton instance which just works with little overhead.
In this case we might consider changing defaults. For Camunda Run, according to the docs, you need to explicitly add the --production flag to run it in prod mode, this could surprise many people. But that’s a different topic
I started writing this response opposed to just naming it “Operaton”, but while writing I argued with myself enough to like the idea
We should ask ourselves: “what is the default way we would like our users to use the engine”.
In my oppinion using the external task pattern by default is a sensible engineering decision for many projects. Integrating the engine into your Spring Boot project is possible if you need to, but is not the “default” option.
Therefore I concur with Julian, Karsten and you on this.
We should then definitely run it production mode by default to prevent surprising our users. For local development we can add a --dev flag.
@javahippie also on the Download page “Operaton” as the default should be on the top of the list .
I agree that Run is the default for provided distributions, although the embedded engine pattern is the most used overall in my experience.
So I’m still on board with renaming “Camunda Run” to just “Operaton” on the distribution list. In general communication we need to be careful not to call it the default architecture, as it provides way more overhead than the embedded engine pattern
