Simplify registry quickstart

[carlesarnal]

No description provided.

[carlesarnal]

cc @bibryam.

[carlesarnal]

@wtrocki this simplifies the service registry quickstart to only have one producer and one consumer instead of having two processes both producing and consuming.

[wtrocki]

@carlesarnal Happy to help with review. Was this discussed with @bibryam just to make sure that we have approval on how this aligns with the guide?

[carlesarnal]

Yes, this was explicitly requested by @bibryam so we can simplify the instructions in the guide.

[wtrocki]

Perfecto. On this now!

[wtrocki]

[Question]
What is the benefit of having separate consumer and producer if we run them separately.
From configuration point of view we can then have single application.properties etc.

That will also simplify our SBO integration in later phase.
No strong opinion on this but considering couple factors:

• Maintenance of the example/quarkus version updates will be easier
• Testing and automation
• Less code to maintain and chance to diverge.
• More aligned with Kafka example as this is single module

Drawbacks:

• Obviously not canonically correct (most the apps doesn't produce and consume at the same time)
• Less of quickstart for users (producting/consuming flags will be mixed together)

[carlesarnal]

I think the idea behind this is exactly what you mention as a drawback, to give users the simplest but realistic quickstart. As you said, in a real environment the producer and the consumer will be different applications. I don't have a strong opinion here either. @bibryam thoughts?

[wtrocki]

I do have strong opinion as my point of view is global (considering current and future services) +
maintenance considerations so please feel free to ignore me but..

Realistic quickstart drawback can be addressed by comments in application properties.
Having all config visible in a single property file is actually saving a lots of time (and guide steps)
There is also the second argument which is eventual confusion - we have 2 apps but they run as a single process that might also make the openshift deployment (SBO) guide a little bit confusing.

Using single module will cut some boilerplate code. It will also allow us to build up continuous tutorial - like Kafka guide that we have now can be adjusted to service registry scenario and that will require making changes in Kafka guide itself.

[carlesarnal]

I understand your points and I think they make sense, I will leave the decision to Bilgin. @bibryam What do you prefer?

[wtrocki]

I have reviewed it locally. Good go merge from my point of view. Suggestions around making it single module are optional.

[bibryam]

@wtrocki when I requested these changes to the quickstart, and included you and @smccarthy-ie in the email to explain why.
I prefer to have 2 processes as that explains better the reason for using RHOSR in a Kafka applicaiton. SR can help prevent changes that producer is making to the schema and not break the consumers. If producer and consumer are in the same process, there is no need for SR at all.

I trust your judgement that will be harder later, especially for SBO example, but I need to see that and see how SBO will fit into our example. I need to investigate that, but I'm guessing I expect two have 2 containers running producer and consumer separately in that scenario. That is what maps to the 2 processes running locally right now. We need to discuss this further, but let's proceed with the example as it is.

[bibryam]

@smccarthy-ie how do you want to proceed with updating the draft based on this new example? This should simplify it. Happy to review once you have gone through it? Or let me know if you prefer me to do the changes first.

[wtrocki]

Agreed! let's merge all changes! No need to split right now.
We can incorporate SBO without issues

[smccarthy-ie]

@bibryam @wtrocki @carlesarnal I can update the latest draft docs based on these changes to the code and will ping you all on the PR for technical review. Thanks!