Amazon MQ – Managed Message Broker Service for ActiveMQ(aws.amazon.com)
aws.amazon.com
Amazon MQ – Managed Message Broker Service for ActiveMQ
https://aws.amazon.com/blogs/aws/amazon-mq-managed-message-broker-service-for-activemq/
10 comments
We would probably use this tomorrow (replacing self managed Rabbit MQ instances) if celery/kombu supported ActiveMQ. Might be the service that generates the volunteers needed to add ActiveMQ support to Kombu. (Not ruling out attempting this myself either).
> With Amazon MQ support standard protocols for messaging, including JMS, NMS, AMQP, STOMP, MQTT, and WebSocket. This allows you to move from any message broker that uses these standards to Amazon MQ–along with the supported applications–without rewriting code.
Celery/kombu speaks AMQP, which is natively supported by AmazonMQ, so you might be able to move to it with no changes to your app.
Celery/kombu speaks AMQP, which is natively supported by AmazonMQ, so you might be able to move to it with no changes to your app.
You sure that's AMQP 1.0 or 0.9? I say that b/c ActiveMQ is AMQP 1.0 (http://activemq.apache.org/amqp.html) and RabbitMQ is probably running 0.9 unless you are using the experimental 1.0 plugin.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.
Maybe, I'll probably try to spin up an instance and test it. But the celery docs call out explicit lack of support for STOMP and ActiveMQ here http://docs.celeryproject.org/en/latest/faq.html#can-i-use-c...
Interesting choice, wonder why they didnt go with Apache Apollo which is supposed to be the successor to ActiveMQ, or newer systems like RocketMQ or Apache Pulsar.
I believe Apollo was abandoned in favor of Artemis[1] which is based on RedHat's donation of HornetQ. But yea, the community doesn't seem to have rushed to adopt Artemis so it looks like AWS is starting where the numbers are.
The Amazon MQ UI specifically mentions which "Engine" is being used so hopefully there will be other options in the future. Similar to how RDS and Elasticache support multiple DB/Cache Engines.
1. https://activemq.apache.org/artemis/
The Amazon MQ UI specifically mentions which "Engine" is being used so hopefully there will be other options in the future. Similar to how RDS and Elasticache support multiple DB/Cache Engines.
1. https://activemq.apache.org/artemis/
They're targeting the massive existing customer base for ActiveMQ, from the blog post: "SQS and SNS have been used extensively for applications that were born in the cloud. However, many of our larger customers are already making use of open-sourced or commercially-licensed message brokers."
My guess: Market share. Go where the $$$ is. For AWS, if they were thinking about Apollo, they would be more likely to try and out-compete it before it gets a foothold.
This is interesting but I don't want serverful queueing
I'd like it if SQS had priority queues.
I'd like it if SQS had priority queues.
My biggest miss on SQS is > 15 minute delays
I have never had a delay more than 45 seconds... that is of course anecdotal.
I mean intentional delays. SQS caps at 15 minutes for that. I often want to just do something trivial like "send this email in 2 hours" and need a non-SQS queueing system, or a hack on SQS with requeueing, to support that
Ah, sorry, I misunderstood. I rarely use the delayed execution feature, I was unaware it was that low.
Yes, this is my main wish for SQS. I like SQS and SNS since they are serverless and work really well but I feel like they have not been updated in years.
ActiveMQ has been around for a long time (along with JMS), with pub/sub, broadcast, queues, transactions, etc. So can anyone tell me why things like Kafka have seen such interest in the last few years?
Is it just another example of an improvement to a long existing solution - the advantage being that Kafka easily scales horizontally? Obviously, great for the minority of projects that actually need it, but just another example of a fad for the 90% who would be just fine using the tried and true, but unhip solution.
Is it just another example of an improvement to a long existing solution - the advantage being that Kafka easily scales horizontally? Obviously, great for the minority of projects that actually need it, but just another example of a fad for the 90% who would be just fine using the tried and true, but unhip solution.
You can also easily rewind the Kafka stream back to the beginning of time, with compaction (if you keep that much data around).
Does this hook into services like SQS does? For example, we use SQS to listen for S3 events and would love to switch to AMQ...but not if we need to wire it up to S3 manually.
You could wire this up with a Lambda middleware function: S3 -> Lambda -> AMQ
https://aws.amazon.com/amazon-mq/pricing/ is a 404 right now and it still isnt listed on the main products page. Although from the screenshot it looks like its micro for $0.03 and large for $0.30 plus storage. Not an amazing price imo given how easy it is to run activemq, but not terrible either.
It's available in the console - pricing & costs(US):
mq.t2.micro $0.03 per hour
mq.m4.large $0.3 per hour
Storage $0.3 per GB-month
Looks like its limited to a single node or HA pair.
mq.t2.micro $0.03 per hour
mq.m4.large $0.3 per hour
Storage $0.3 per GB-month
Looks like its limited to a single node or HA pair.
Sounds interesting, but I'm pretty sure we need to keep out ActiveMQ instance in local machines because of medical data. We're also pretty tied to GCS...
like almost everyone else, AWS adds services to it's list of PHI approved services that customers with a BAA can utilize for PHI. AWS has done a phenomenal job getting services added to the BAA Service List over the past 6 or 8 months; there is a lot of emphasis on it now.
Where in the CFR does it say you have to use physical servers or even dedicated cloud instances? AWS will sign a BAA for dedicated instances only (biz policy, not for any valid security reason), but dedicated servers are not required by HIPAA.
The requirement for dedicated instances was lifted earlier this year. See https://aws.amazon.com/blogs/apn/aws-hipaa-program-update-re... for more info.
Thank you! Slipped by my addictive refresh of What’s New!
About time. Before this the only managed choice within AWS was IoT, which definitely felt not quite right for just some MQTT/websocket work.
I will have to give this a look. We manage our own MQ currently but autoscaled managed MQ would be the dream. SQS simply did not meet our needs.
It's weird to see a username & password step there, one big benefit of keeping everything within AWS is how easy it is to give anyone on the team access to whatever they need without creating new passwords for everyone (or worse, sharing a shared password if you can only have one login). Now if I use ActiveMQ it's another password that will need to be managed, rotated, revoked when people leave the company, etc.
This looks like a cool product, but I hope it doesn't turn out to be another AWS Elasticsearch Service (which is the worst of both worlds in having a frustratingly leaky abstraction layer between the underlying open-source tools and the AWS wrapper, but still having a sufficiently complex layer that it's too hard for AWS to keep up with the latest versions).
Hopefully ActiveMQ service can at least run in a VPC?