Hi Justin,
I'm fully agree with your vision.
I was just thinking if it will not be much efficient for Artemis to be
an independant Apache project to be more visible.
I know that this is a long story and I don't want to restart the old
discussion thread but may be it's an adoption blocker for Artemis to be
under the umbrella of the ActiveMQ project.
Regards,
Francois
On 30/09/2022 21:11, Justin Bertram wrote:
Some musings on a Friday afternoon...
In my experience companies choose their software platforms for a myriad of
reasons, some of which are not obvious or intuitive. Without specific
comment from the cloud providers you mentioned we are only able to
speculate about their motivations.
There's no doubt that ActiveMQ "Classic" is very widely used. It's been the
de facto standard Open Source JMS broker since 2007. At the risk of
additional speculation, I think this is why many cloud providers offer
ActiveMQ "Classic" on their platforms.
Generally speaking, there is a mountain of money to be made by cloud
providers from coaxing organizations to move their existing work-loads to
the cloud. I'm sure there are many, many aging deployments of ActiveMQ
"Classic" employing basic JMS use-cases with relatively low message
throughput. It makes sense for a cloud provider to offer the smoothest
migration strategy possible for these kinds of deployments. I can imagine
that cloud providers are looking for the best return on their investment
and asking organizations to move to the cloud *and* to change brokers is a
much higher risk for them no matter what the alternative broker might be.
Getting these organizations to move *any* workload onto their platform is
also a great way to upsell and cross-sell them for even more gains.
In my opinion it is a compelling strategy, but one that speaks more about
finances than the technical merits of either broker.
Justin
On Fri, Sep 30, 2022 at 7:46 AM fpapon <fpa...@apache.org> wrote:
Hi,
Thanks for all these feedbacks, this is very interesting!
When searching on the web, I can see that most of SaaS providers provide
ActiveMQ Classic (AWS, Azure, Oracle....) not because of performance but
more because of stability of the solution.
I'm not saying that Artemis is not stable but people seems to think that
as ActiveMQ Classic is more widely use, they prefer to go with it for
stability purpose.
I saw that ActiveMQ Classic is available on docker, with persistence
storage and also the network of broker feature for connecting
on-premise/cloud brokers.
https://aws.amazon.com/blogs/compute/running-activemq-in-a-hybrid-cloud-environment-with-amazon-mq/
https://blogs.oracle.com/cloud-infrastructure/post/high-availability-for-activemq-with-mysql-and-kubernetes-on-oci
Regards,
Francois
On 29/09/2022 21:47, Justin Bertram wrote:
Your use-case as stated is straightforward, and either broker could
handle it functionally no problem.
I see a potential risk regarding HA. ActiveMQ "Classic" only supports
HA via a shared store whereas Artemis supports both shared store and
replication. If you can't or simply don't want to configure shared
storage or shared storage is too slow then Artemis would be your only
option. Replication can be nice as it eliminates the shared store as a
single point of failure and the brokers get the performance benefit of
using local disks.
Here's a few forward-looking potential risks:
1) Since you're basically using JMS exclusively there may be a risk
if you ever need to move to JMS 2 or Jakarta Messaging 2.0 or 3.0.
Artemis already ships clients with full support for these APIs. Given
recent messages on the mailing list I believe there are plans to
implement this support for ActiveMQ "Classic," but it may be that a
bird in the hand is worth two in the bush, as they say.
2) If your load increases substantially or your performance needs
become more aggressive (or both) then you may hit a ceiling with
"Classic" where you can't get the numbers you need.
That's all I can think of off the top of my head.
It's hard for me to comment on the K8s angle as I don't work much in
that area, but https://artemiscloud.io/ may be a helpful resource for
you.
Justin
On Thu, Sep 29, 2022 at 1:16 PM John Lilley
<john.lil...@redpointglobal.com.invalid> wrote:
Greetings,
I can see this question has been asked in some form before, and
recently. But I just wanted to clarify our use case and ask which
version would be a better bet going into production in a few
months. Some details:
* Client/service access is 99% via JMS, except for a few
management methods (enumerate queues, get queue count) which
we hit via Jolokia
* Usage is 95% RPC (post to named queue, reply on temp queue)
and 5% topics
* AMQ has been working in test for many months. Artemis is
being tested and we are shaking out a few semantic differences.
* Our performance needs seem to be covered by both versions.
* We don’t need HA yet. HA is on the roadmap for 2023.
* We need persistence (so messages are not lost if broker is
bounced)
* We are in a Kubernetes pod environment. The broker itself
**can** run in a separate VM if that is the preferred or
more-stable configuration.
We realize the Artemis is the future, so we are inclined that way
if possible.
In order to avoid opinion wars, I really just want to ask “what
are the known risks” for the two options. Given that we are in
K8S, does one have better K8S support/experience over the other?
Secondary question: is it OK to deploy the broker in K8S pods, or
is it better to use a dedicated VM?
Thanks
john
rg <https://www.redpointglobal.com/>
John Lilley
Chief Architect, Redpoint Global Inc.
888 Worcester Street, Suite 200 Wellesley, MA 02482
*M: *+1 7209385761 <tel:+1%207209385761> |
john.lil...@redpointglobal.com
PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is
confidential and is intended solely for the use of the
individual(s) to whom it is addressed. If you believe you received
this e-mail in error, please notify the sender immediately, delete
the e-mail from your computer and do not copy, print or disclose
it to anyone else. If you properly received this e-mail as a
customer, partner or vendor of Redpoint, you should maintain its
contents in confidence subject to the terms and conditions of your
agreement(s) with Redpoint.
--
--
François
--
--
François
