I have a Hybris deployment on a single Weblogic Managed Server. The problem is during performance testing it was found that it would be better to split the Hybris modules like Admin Cockpit and Product Catalogue to different Managed Servers.
EDIT
I Suppose I should also mention the fact that my Infra Team is asking me to separate out the EARs so that in case of code changes, only the affected module gets redeployed and not the whole bunch. That way even if we let the performance front out, still I need the splits
Now my problem is that for build Hybris produces a single EAR file.
Is there a way, in which I can break down the EAR file and have the modules optionally there...
So the structure would be:
Managed Server 1
Managed Server 2
After this the links to the deployments be redirected via URL configuration
Any Suggestions??
I'm not sure if this will eliminate the problems you encounter as I don't think the admin cockpit by itself will be causing a performance bottleneck. What is the performance issue? Quite often performance impact can come from admin/backend triggered functionality like e.g. cronjobs (e.g. updating product catalog with stock/product information), or solr indexing jobs etc.
One common approach I have seen in hybris cluster environments is to setup a cluster of multiple nodes and have one node reserved for backend activity (so that expensive cronjobs run on a dedicated node that is not served by the load balancer handling storefront requests). But I think from a code deployment perspective the artifact would still be the same. Hope this helps at least as food for thoughts :)
EDIT
In short: Multiple hybris servers accessing the same db need to be setup as cluster. Multiple hybris servers with different sets of extensions can't share the same db (as the db layout will be different).
To be honest, this doesn't sound like a good approach to me. In hybris you would use different localextension.xml files (which define which extensions (i.e. modules) are part of your code artifact). That being said, if you have two vastly different localextensions.xml files (one for your product catalog and one for admin) the resulting 'admin' deployment artifact would not contain the data model of the 'catalog' deployment, so the persistence layer wouldn't match up. In other words, in your admin server you wouldn't be able to even see the data model that is defined in your 'catalog' server because the 'catalog' specific extensions are not installed.
And if you go without a properly set up cluster environment, changes on one server (written down to the db) wouldn't be noticed on the other server unless you actively refresh/purge the hybris cache there either, so multiple hybris servers sharing the same db is only functioning if the servers are set up as a cluster.
I think if your admin server is supposed to work on the actual 'catalog' data, they both need to have the same set of extensions defined in their localextensions.xml in order for it to work at all. Sharing the same database without being aware that there is a cluster (or basically other hybris servers accessing the same db) is not going to work IMO.
I still think your best shot would be to deploy the same code artifacts (in cluster environments you can still setup different behavior/configuration per node). You could still (if you are 100% sure of it) deploy a new release with code changes that affect only your 'catalog' node only on that catalog node if you want to reduce downtime etc, but its always a risk if you have a cluster with different deployments on each node.
Good luck :)