Application Environments

[Google <ch...@gmail.com>]

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

Re: Application Environments

[Sijie Guo <gu...@gmail.com>]

If " given that some apps only support some environments and only a few
support all, we need to route between them." is the case you are facing,
I'd recommend using option 4.

You can write a function to route messages to the different application
environment-specific topics.

- Sijie

On Sun, Nov 8, 2020 at 5:05 PM Google <ch...@gmail.com> wrote:

> 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
>
>
>    1. *tenant* - /qua-sap/product/price
>    2. *namespace* - /sap/qua-product/price
>    3. *topic* - /sap/product/qua-price
>    4. *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
>    5. *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
>
>