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
Kubernetes
Score 9.3 out of 10
N/A
Kubernetes is an open-source container cluster manager.
N/A
Pricing
Apache Kafka
Kubernetes
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
Apache Kafka
Kubernetes
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Apache Kafka
Kubernetes
Features
Apache Kafka
Kubernetes
Container Management
Comparison of Container Management features of Product A and Product B
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).
Along with all the best features and support by k8s, the automatic container scheduling to worker nodes and also self-healing containers which is what I like the most. On the other side, when I was installing the k8s cluster on CentOS 8, it was quite difficult for me, but never mind it is working as we expected and it is a one-time effort. Especially, in my case, there are more than 7 application containers required to run and communicate with each other, so for us, Kubernetes is an optimal solution.
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.
Local development, Kubernetes does tend to be a bit complicated and unnecessary in environments where all development is done locally.
The need for add-ons, Helm is almost required when running Kubernetes. This brings a whole new tool to manage and learn before a developer can really start to use Kubernetes effectively.
Finicy configmap schemes. Kubernetes configmaps often have environment breaking hangups. The fail safes surrounding configmaps are sadly lacking.
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.
The Kubernetes is going to be highly likely renewed as the technologies that will be placed on top of it are long term as of planning. There shouldn't be any last minute changes in the adoption and I do not anticipate sudden change of the core underlying technology. It is just that the slow process of technology adoption that makes it hard to switch to something else.
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
It is an eminently usable platform. However, its popularity is overshadowed by its complexity. To properly leverage the capabilities and possibilities of Kubernetes as a platform, you need to have excellent understanding of your use case, even better understanding of whether you even need Kubernetes, and if yes - be ready to invest in good engineering support for the platform itself
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.
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.
As I said earlier also - - K8s manage the workloads better as compared to OpenStack in terms of reliability, observability & reachability. - K8s is not limited to only a single networking or storage solution as compared to OpenStack. - Networking (which is a key concept) is much simpler in K8s as compared to OpenStack. - It is possible to upgrade your applications without downtime in K8s but in OpenStack, you either have to divert the traffic or face an outage because you have to delete the whole stack & then recreate it.
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.
