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
Oracle Hospitality - MICROS POS
Score 1.0 out of 10
N/A
Oracle Hospitality is the successor to MICROS eCommerce software, modular software dedicated to the needs of airlines, hotels and resports, sport venues, restaurants and bars, and others.
The MICROS Point-of-Sale (PoS) systems are available and now offered by Oracle since the acquisition of MICROS Systems in 2014, and are now part of the Oracle Hospitality 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.
In my experience, there has not been a resolution on outstanding tickets opened two years ago during the initial implementation. Simple things like time reporting, creating buttons, and marking items as "unavailable" have issues. The system has a lag when servers log out of checks that prevents them from opening the checks on another terminal without a wait that feels like an eternity in the restaurant industry and with direct impact to the guest. Good luck calling support. Most of my experience involves the person I spoke with having no idea how to fix my issue and having to "escalate the ticket." This escalation process will last weeks, months, and in our case, years with no resolution.
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).
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
Support is awful. Oracle does not directly support end-users and depends on resellers to offer support. So if there is a bug or breaking change, we have to jump through hoops to get something fixed.
Does not play well with other software or interfaces. There are interfaces but they lack a serious amount of features that are crucial to our business.
The guest facing hardware does not hold up to constant use very well.
The backend hardware is lacking in PCI compliance and is not meant for enterprise use.
The software itself looks as if it is stuck in the early 2000s and there has been no sign of an update in many years.
Reporting is difficult to set up and use and you have to rely on third-party reporting to get decent usable reports.
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
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.
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.
We've stayed with MICROS mainly due to that's how we've always operated and to switch operating POS systems would be a HUGE learning curve for everyone involved.
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.
Micros has allowed us to leverage our margin by using our own credit processor and loyalty program. We've seen success from both of these platforms (not Micros) and have been able to save money on the extra costs of using Micros.
