[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: Artemis vs AMQ 5.x in production
From:       Justin Bertram <jbertram () apache ! org>
Date:       2022-09-30 19:11:53
Message-ID: CAF+kE=QrD2-TOZhYLqBygtvMh11ACW5XEQDadBBv8DJx-PgZVA () mail ! gmail ! com
[Download RAW message or body]


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 <fpapon@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.lilley@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.lilley@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
> 



[prev in list] [next in list] [prev in thread] [next in thread]