Hi,
Our company has a misguided concept of “environments” where two set of
infrastructure deployments TEST and PROD are used to support a number of
application level environments. Something like
PROD - Production
TEST - Development (dev), Quality (qua), Validation (val) and Staging (stg)
If these “application environments” were available for all apps it might have
worked fine but given that some apps only support some environments and only a
few support all, we need to route between them. It’s a mess, but without a top
level executive decision this won’t change anytime soon...
How do I be organise the topics?
Given Price events for Products published by the SAP I would ideally like to
use the following fully qualified topic name
/sap/product/price
… where SAP is a tenant, product is the namespace and price is the topic. As we
need to publish Price events in the dev, qua, val and stg environments on the
same TEST infrastructure what is the best way to handle this?
The application environments could be reflected in the
tenant - /qua-sap/product/price
namespace - /sap/qua-product/price
topic - /sap/product/qua-price
message - /sap/product/price where each message has an environment property and
we use a function to route messages to topics like /sap/consumers/my-app-qua
instance - /sap/product/price where I provision a new clusters for each
environment
Options 1-3 are… ugly but is anyone better than the other?
Option 4 would mean that each topic get up to four times as many messages, also
am I still really doing PubSub?
Option 5 means wasting resources in particular as not all apps use all
environments also it feels wrong to connect say a dev app to a qua cluster…
For Option 4 It would have been cool if the client could have a filter defined
on the connection...
Any advice short of convincing upper management to put down the foot and
standardise across the board?
Best regards,
Christoffer
