Apache Kafka vs. Oracle BPM Suite

Apache Kafka is well-suited for most data-streaming use cases. Amazon Kinesis and Azure EventHubs, unless you have a specific use case where using those cloud PaAS for your data lakes, once set up well, Apache Kafka will take care of everything else in the background. Azure EventHubs, is good for cross-cloud use cases, and Amazon Kinesis - I have no real-world experience. But I believe it is the same.

Oracle BPM is well suited to organizations and environments that have a good understanding of their business processes and organizational structures. Trying to introduce a tool such as Oracle BPM into the organization without a good grasp on how the business operates is a recipe for disaster as the implementation will uncover all of the dirty secrets of an organizations business processes and bring them to light. BPM is not to be utilized for smaller service orchestrations or technical service implementations, these should be handled by the Oracle SOA Suite using the BPEL process manager, leaving BPM to handle the organizational business processes, referring to and including lower level services and BPEL processes as needed.

• Really easy to configure. I've used other message brokers such as RabbitMQ and compared to them, Kafka's configurations are very easy to understand and tweak.
• Very scalable: easily configured to run on multiple nodes allowing for ease of parallelism (assuming your queues/topics don't have to be consumed in the exact same order the messages were delivered)
• Not exactly a feature, but I trust Kafka will be around for at least another decade because active development has continued to be strong and there's a lot of financial backing from Confluent and LinkedIn, and probably many other companies who are using it (which, anecdotally, is many).

Incentivized

• Oracle BPM [Suite] can support unlimited number of cases. No limitations in cases raised.
• Oracle Weblogic can handle multiple traffic. [It] can handle lots of heavy load[s].
• Oracle BPM has extensive integration with database[s]. Huge number[s] of customization can be created.

Incentivized

• Sometimes it becomes difficult to monitor our Kafka deployments. We've been able to overcome it largely using AWS MSK, a managed service for Apache Kafka, but a separate monitoring dashboard would have been great.
• Simplify the process for local deployment of Kafka and provide a user interface to get visibility into the different topics and the messages being processed.
• Learning curve around creation of broker and topics could be simplified

• Oracle BPM is left behind by other tools more modern in terms of user experience, usability and ability to integrate with everything else.
• To really harvest the potential of Oracle BPM you need to do it in JDeveloper and with ADF. This restricts its usage to very technical people.
• The administration of the Oracle BPM tools has really put a burden on our team. It is running on Weblogic and we experience issues very often either with performance or with a bad configuration of the system.
• As with all Oracle products, the price can be an issue for smaller shops.

Incentivized

Kafka is quickly becoming core product of the organization, indeed it is replacing older messaging systems. No better alternatives found yet

Incentivized

In many scenarios it should have provided more features. It took a lot of effort while debugging, making it difficult to maintain.

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

Incentivized

Not easy to debug errors.

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.

Incentivized

Overall satisfactory

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 to other needs.

Incentivized

We evaluated Bonita and found that it might fit a smaller-sized company better; we found that Oracle BPM Suite scaled much more evenly. We almost went with one of the competitors, but in the end chose Oracle BPM Suite after we factored in the cost of VMware licensing. There are literally tons of analytics on the back end which are great for upper management, but not so much for average users, but this fits our business model quite well.

Incentivized

• Positive: Get a quick and reliable pub/sub model implemented - data across components flows easily.
• Positive: it's scalable so we can develop small and scale for real-world scenarios
• Negative: it's easy to get into a confusing situation if you are not experienced yet or something strange has happened (rare, but it does). Troubleshooting such situations can take time and effort.

Incentivized

• You'll most certainly need a deep dive and extensive training before your users can even think of using the product and they are very expensive.
• Lack of documentation makes it very difficult to manage the application if any error is encountered which will result in you ending up hiring a dedicated person to look into the application once it's deployed.
• For a very large org., if properly implemented and used, it can help identify the cost-intensive and inefficient processes.

Incentivized