What I Learned From Building Apache Kafka At LinkedIn
Apache Kafka – Here are a few things.
Begin with the end in mind
Kafka wasn’t the first open source project I was involved in at LinkedIn. We’d also built a key-value store, a workflow system, and a number of other things. The biggest difference with Kafka was that I think we were much more intentional about the space and what would be possible. The other projects began as quick hacks or pet projects. By the time I started working on Kafka, I had much more perspective on the larger technology ecosystem and what problems would be worth solving. The basic thesis was that the advances in distributed systems made it possible to build all kinds of horizontally scalable data systems, and that one of the biggest gaps would be how all the data and applications in a big digital company plugged together. We thought there could be some data fabric for this in the same way relational databases backed individual apps. This was very much about solving back from the end state of how a company would work and then attacking the most important part of that.
I think people underestimate this kind of “end state” thinking in the early part of a project because the early progress and impact are nowhere close to reaching that end state vision, so the difference isn’t immediately observable. In the early use cases both the job scheduler and Kafka were pretty valuable. The big difference was about what they could grow into.
Investors often think about this as the “addressable market” for a company. If the market is limited that will be the ultimate constraint on the company’s success. I think people should think about investing their time in a similar way.
New categories are hard
When we open sourced the key value store LinkedIn built, it was immediately pretty successful and got production adoption. I didn’t realize originally how much of this was because it was easy to place in existing categories. Basically it was a database, and people knew what that was, and the abstraction it provided was a distributed hash table, and programmers understand hash tables. So the level of effort to understand what it was and where it might be useful to you was really low.
Kafka was the opposite. It was something genuinely new. Kafka addressed some problems message queues had, but was really something quite different: a kind of database or filesystem for large scale event stream storage and processing. We eventually started calling this an “event streaming platform” but at the time we didn’t really have a phrase for it.
This made it really hard to get adoption for Kafka early on because there wasn’t really an existing category that answered the “what is it?” question. I often say that Kafka was released to “resounding silence”.
This actually cuts the other way over time, I think. There are a lot of positive aspects to doing something genuinely new because once it starts to catch on, you get to be emblematic of the new trend and category.
This article originally appeared on forbes.com To read the full article, click here.
Nastel Technologies uses machine learning to detect anomalies, behavior and sentiment, accelerate decisions, satisfy customers, innovate continuously. To answer business-centric questions and provide actionable guidance for decision-makers, Nastel’s AutoPilot® for Analytics fuses:
- Advanced predictive anomaly detection, Bayesian Classification and other machine learning algorithms
- Raw information handling and analytics speed
- End-to-end business transaction tracking that spans technologies, tiers, and organizations
- Intuitive, easy-to-use data visualizations and dashboards
If you would like to learn more, click here.