Absolutely Paul. In fact, we ran 12 apps, 6 against one EAC and 6 against another EAC for a period of about 6 weeks in a high volume production environment.
Kaush - the use case for us was during migration from 2.1 to 3.1 - we had the old stack running, then installed a new stack of EAC/Workbench and ran them side by side. Then as the apps were upgraded, we just pointed them from the old Dgraph to the new. That way we didn't have to do a big bang approach.
EAC 6.1.3 (on port 8888) --- WB 2.1.2 (on port 8006)
MDEX 6.4.1 <
EAC 6.1.2 (on port 18888) --- WB 3.1.2 (on port (18006)
For your use case Paul, I can't see why you couldn't have both EAC be the same version. You just need to install then into two different directories and have them listen on 2 different ports. In our case, both pointed to the same MDEX installation.
Thanks for the responses. I think I'll go ahead with it - the only reason I was hesitating was a comment from an Endeca support engineer a while back that it was not recommended to have more than one EAC controlling apps in a cluster of Dgraph servers.
Our use case: we have a really big application running on the production servers. We do updates in a separate staging environment, copy the indexes/partials across to the production environment after sanity checks and apply them from a master EAC in the production cluster.
Now we want to install a much smaller, simpler less-critical app on two of the production servers. I'd still like to run the updates in the staging environment, but want to manage the production dgraphs also from the staging environment, and have the updates be applied there along with the staging one - so I don't want to provision this as a separate app in production, unlike the main app.