No, but I’ve definitely been tempted, at least for low risk/ dev environments, but haven’t pulled the trigger. I’m awaiting to give it a good spin first. I’ve been looking for something like this post though.
FWIW I’ve been reluctant mostly because having new folks working with Kafka is tricky enough without additional “Kafka compatibility “ issues popping up. Similar to the reasoning that had us decide doing kstreams in Java instead of scala or clojure. I’d file it as “nice but will break the innovation budget”.
I believe it was popularized by this blog post from 2015: Choose Boring Technology. There it was conceptualized as innovation “tokens” like in friendlysock’s comment earlier.
The concept of an “innovation budget” is something that is super important for all engineers, especially folks at a startup.
Every team has some finite number of innovation tokens, which may or may not replenish over time. If you spend all of your innovation tokens on, say, building your webserver in Rust then you really can’t afford to do more exotic things like microservices or blue/green deploys or whatever else.
Similarly, the model goes, if you pick a really boring webstack and ops stuff (say, modern-day Rails on Heroku), then you can spend those innovation tokens on more interesting problems like integer programming for logistics or something. The business version of this would be deciding to support multiple vendors or go with a new payment processor instead of just trusting Stripe or Braintree or whoever.
My extension to the model is that, in a startup, you can exchange innovation tokens for efficiency tokens or cost coupons…if you build your stack in bespoke Julia it’s a lot harder to hire (and a lot harder to backfill departures!), whereas if you go with python or javascript then you can easily find interns or bodyshops to round out the workforce.
One of the great open questions to me about the model is: how does an org deliberately replenish innovation tokens?
One of the great open questions to me about the model is: how does an org deliberately replenish innovation tokens
Apologies for necroing an old thread here but this just popped into my head: you can recycle an innovation token by using a given piece of originally-interesting technology until over time it becomes boring. This works if you’re huge or there arises a large community around it.
Rails is a prime example of this. It used to be an interesting choice and now it’s offered up as an example of a boring technology.
Is anybody using Redpanda instead of Kafka at work?
I’d run a PoC at work (and even found a minor bug). In my use-case the performance was exactly the same. In the end this did not move forward as I switched teams inside the organization and the old team went ahead with a managed service.
As always, a nice and thorough report. Good work @aphyr!
Is anybody using Redpanda instead of Kafka at work?
No, but I’ve definitely been tempted, at least for low risk/ dev environments, but haven’t pulled the trigger. I’m awaiting to give it a good spin first. I’ve been looking for something like this post though.
FWIW I’ve been reluctant mostly because having new folks working with Kafka is tricky enough without additional “Kafka compatibility “ issues popping up. Similar to the reasoning that had us decide doing kstreams in Java instead of scala or clojure. I’d file it as “nice but will break the innovation budget”.
This may be the first time I hear the term: “innovation budget”. Astonishingly fitting.
Sidenote if this topic is interesting to you: it was a principle in Rusts development under the name of “strangeness budget”.
https://steveklabnik.com/writing/the-language-strangeness-budget
I believe it was popularized by this blog post from 2015: Choose Boring Technology. There it was conceptualized as innovation “tokens” like in friendlysock’s comment earlier.
The concept of an “innovation budget” is something that is super important for all engineers, especially folks at a startup.
Every team has some finite number of innovation tokens, which may or may not replenish over time. If you spend all of your innovation tokens on, say, building your webserver in Rust then you really can’t afford to do more exotic things like microservices or blue/green deploys or whatever else.
Similarly, the model goes, if you pick a really boring webstack and ops stuff (say, modern-day Rails on Heroku), then you can spend those innovation tokens on more interesting problems like integer programming for logistics or something. The business version of this would be deciding to support multiple vendors or go with a new payment processor instead of just trusting Stripe or Braintree or whoever.
My extension to the model is that, in a startup, you can exchange innovation tokens for efficiency tokens or cost coupons…if you build your stack in bespoke Julia it’s a lot harder to hire (and a lot harder to backfill departures!), whereas if you go with python or javascript then you can easily find interns or bodyshops to round out the workforce.
One of the great open questions to me about the model is: how does an org deliberately replenish innovation tokens?
Apologies for necroing an old thread here but this just popped into my head: you can recycle an innovation token by using a given piece of originally-interesting technology until over time it becomes boring. This works if you’re huge or there arises a large community around it.
Rails is a prime example of this. It used to be an interesting choice and now it’s offered up as an example of a boring technology.
I’d run a PoC at work (and even found a minor bug). In my use-case the performance was exactly the same. In the end this did not move forward as I switched teams inside the organization and the old team went ahead with a managed service.