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.
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.
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."
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.
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.
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.
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.
Yeah, i edited my comment because i did a quick search to see if they had implemented SNS filtering and turns out they did. I'll be telling my team about that tonight
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
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.
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.
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.
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.
Are there any plans to integrate IAM roles with the ActiveMQ login portal?
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?
30 comments
[ 4.1 ms ] story [ 83.2 ms ] threadThe 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/
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.
I'd like it if SQS had priority queues.
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.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.
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.
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?