Apache Kafka is an open-source stream processing platform developed by the Apache Software Foundation written in Scala and Java. The Kafka event streaming platform is used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
N/A
AWS IoT Core
Score 9.9 out of 10
N/A
AWS IoT Core is a managed cloud service that lets connected devices interact with cloud applications and other devices. It includes the Device Gateway and the Message Broker, which connect and process messages between IoT devices and the cloud. AWS IoT Core connects AWS and Amazon services like AWS Lambda, Amazon Kinesis, Amazon S3, Amazon SageMaker, Amazon DynamoDB, Amazon CloudWatch, AWS CloudTrail, Amazon QuickSight, and Alexa Voice Service to build IoT applications that gather, process,…
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data …
Apache Kafka can work at a higher scale as compared to SQS. It can work with higher size per message and millions of messages per second. Moreover it can be scaled horizontally by adding more brokers to the cluster. SQS is good enough for simple use cases like making a task …
I used other messaging/queue solutions that are a lot more basic than Confluent Kafka, as well as another solution that is no longer in the market called Xively, which was bought and "buried" by Google. In comparison, these solutions offer way fewer functionalities and respond …
Apache Kafka is open-sourced, scales great has cloud agnostics and performs better than Amazon Kinesis [in my view]. Amazon Kinesis has some limitations and vendor lockin is not something I [like]. With Confluent operators you can easily install it on a kubernetes cluster.
We really needed to get away from using a SQL database to act as a queue for processing records, so a new solution was needed. Kafka is a leading software application initially designed for queuing messages which is essentially what we were looking for. It has a great user …
For us, Kafka really doesn't have a 1:1 alternative. We have used ActiveMQ extensively and we still use it as a lighter option for small messages. The situation is similar with Redis - although it could be used like a Kafka alternative, we do use it just as a per-component …
Apache Kafka is much more scalable and more reliable. Does not depend on memory, works well on rotational disks and that makes it a cheaper to use solution on low hardware requirements. Running multiple consumers on the same topic can also mean processing the same data again …
All stack tech helps our app and system. These technologies allow us to have the data available faster between different regions (due to our particular configuration) and thus the data and processing load of each system is lower. This allows the systems to be used more …
Kafka is not a real messaging broker implementation as RabbitMQ or TIBCO EMS/JMS are. Although it can be used as messaging, we like the idea behind the Kafka (data isn't "passing by," instead it remains centra, so the client can revisit the data if necessary). This also …
Confluent Cloud is still based on Apache Kafka but it has a subscription fee so, from a long term perspective, it is wiser to deploy your own Kafka instance that spans public and private cloud. Amazon Kinesis, Google Cloud Pub/Sub do not do well for a very number of messages …
I would only use RabbitMQ over Kafka when you need to have delay queues or tons of small topics/queues around. I don't know too much about Pulsar - currently evaluating it - but it's supposed to have the same or better throughput while allowing for tons of queues. Stay tuned - I …
Kafka is faster and more scalable, also "free" as opensource (albeit we deploy using a commercial distribution). Infrastructure tends to be cheaper. On the other hand, projects must adapt to Kafka APIs that sometimes change and BAU increases until a major 1.x version comes out …
Azure IoT is a good product but since our whole suite of tech is now set up in AWS (ec2, s3, sagemaker, cloud formation, etc.), we wanted something that could quickly adapt to our environments. Learning a new tech for IoT was simply a bottleneck that we wanted to avoid at this …
AWS iot core is a good starting point which can be utilized for a variety of enterprise solutions. Barrier to entry to experiment and try AWS iot core is less and AWS eco-system providers ensure that even startups can try a variety of solutions and build key skills and …
Azure IoT service provides more or less the same services as compared to AWS IoT core, however the costing of AWS lead us to continued usage of IoT core over Azure IoT services. Also, considering our existing technology stack is on AWS, it was a natural selection for better …
It turns out that AWS IoT Core is the most mature solution on the market with the best variety of integration tools available. On the downside, it is not the cheapest platform existing out there. Amazon IoT Core is easy to start and set up, and our prior engagement with Amazon …
For our use case, we ended up with AWS because the human resources that were planning to be resourced on this particular project happened to have prior familiarity with the AWS ecosystem. The conversation became can we justify continuing with this ecosystem rather than pivoting …
We have checked other IoT platforms such as IBM Watson IoT and Microsoft Azure IoT, but Amazon IoT Core seems reasonable in terms of pricing and overall functionalities. Amazon IoT Core is easy to start and set up and our prior engagement with Amazon for AWS was a factor to go …
AWS IoT Core is faster, easier, cheaper, and enjoyed by our employees more than Microsoft Azure. We selected AWS IoT because we saw an advertisement for it and have used it ever since. We will continue to use it as long as it is around or until we find one that is better.
We prefer Amazon storage and content delivery S3 services rather than Microsoft Blob Storage. Also, AWS IoT Core seems to be the cheaper alternative compared to Azure IoT.
For brokering messages, Confluent Kafka is well suited since it offers a managed solution ready to use. Scenarios where the solution is not very well suited are for example, where pricing is an issue. The solution costs quite a lot for basic usage (for example: for 3 clusters, pricing is above 100k$ a year).
AWS iot core is very useful if you need to scale very quickly for managing lots of devices without handling the underlying infrastructure cost. It can enable real time publishing and subscription of devices, monitoring and early stage intervention in case of unexpected issues while developing a full stack solution. However, healthcare scenarios where government intervention is needed should be developed and scaled by following the set of compliance policies of the government and the SLA requirements of the customer. Finally, it is great where you need to do data science research after anonymizing data
Apache Kafka is able to handle a large number of I/Os (writes) using 3-4 cheap servers.
It scales very well over large workloads and can handle extreme-scale deployments (eg. Linkedin with 300 billion user events each day).
The same Kafka setup can be used as a messaging bus, storage system or a log aggregator making it easy to maintain as one system feeding multiple applications.
The Kafka Tool is a community-made Java application that looks and feels from the past century.
Logging can be confusing. This certainly shows when we have to do troubleshooting.
Hybrid scenarios - pub/sub, but there are services in and outside a Kubernetes cluster. Then there are a ~3 options, but only 2 (the harder ones) are production-safe.
Kafka has suited our use case very well so far. Going forward we are planning to expand our platform manifold so the load on Kafka and our reliance on Kafka is going to increase only.
Apache Kafka is highly recommended to develop loosely coupled, real-time processing applications. Also, Apache Kafka provides property based configuration. Producer, Consumer and broker contain their own separate property file
I give AWS IoT Core's overall usability this rating because it is very easy to use and is enjoyed by all of our staff. The only problem is that it sometimes glitches and it freezes a lot. So overall, the usability of AWS IoT Core is very good, and we will continue to use it.
Support for Apache Kafka (if willing to pay) is available from Confluent that includes the same time that created Kafka at Linkedin so they know this software in and out. Moreover, Apache Kafka is well known and best practices documents and deployment scenarios are easily available for download. For example, from eBay, Linkedin, Uber, and NYTimes.
It covers all the aspects of IoT services required for an IoT company. It supports all the industry-wide protocols for secure data transmission and integrates powerful AL and ML technology for data analytics. For data storage, Amazon S3 is a great solution. Strong tech support and user community. Since it is widely used as compared to other products, there is an abundance of training and learning material on the web.
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data scale up tremendously. RabbitMQ however has its strengths in traditional messaging. Routing and message delivery reliability are the bedrock of RabbitMQ and this is where RabbitMQ excels. In my previous workplace, RabbitMQ was of choice as reliability matters more than scale. In two words. Apache Kafka for scale, RabbitMQ for reliability. And for cloud deployment and large dataset messaging in what I am doing now, Apache Kafka is the default choice.
Azure IoT is a good product but since our whole suite of tech is now set up in AWS (ec2, s3, sagemaker, cloud formation, etc.), we wanted something that could quickly adapt to our environments. Learning a new tech for IoT was simply a bottleneck that we wanted to avoid at this point.
Positive: bursts of traffic on special holidays are easy to handle because Kafka can absorb and buffer all the messages we need to process long enough to let an understaffed set of back-end services catch up on processing. Hard to put a number to it but we probably save $5k a month having fewer machines running.
Positive: makes decoupling the web and API services from the deeper back-end services easier by providing topics as an interface. This allowed us to split up our teams and have them develop independently of each other, speeding up software development.
Negative: our engineers have made mistakes such as accidentally dropping a few thousand messages due to the CLI being confusing to use, and as a result a customer lost some of their precious data. I'd say that was more our fault than Kafka's though.