eventing

> for that, synchronous APIs quite likely aren’t what you want, event-driven and message-based asynchronous infrastructure would come into play. Which of course what I spent a lot of time working on recently. I wonder how that fits into the K8s/service-fabric landscape? Unfortunately, unlike Envoy and networking, the story for Kubernetes event-driven architecture is not yet as stable. Generally it’s roll-your-own for reliability. Eventually Knative Eventing will serve that purpose, but it hasn’t hit 1.0[1] or anything more stable than that... the CRDs recently made it to beta, though and an initial go at error handling was added relatively recently (mid-to-late last year)[2] 1. https://github.com/knative/eventing/releases 2. https://github.com/knative/eventing/tree/master/docs/deliver...

> Knative is about to hit v1.0 and become «stable», has a solid community. I'm sorry for the negativity but I'm skeptical about the reliability. AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine. My anecdote is, I was at a conference, listening to the "Introduction to Knative" talk. Knew just the name and that serverless is a hot new thing. There was a simple app that has sourced earthquakes and displayed a map, or something like that. Things looked neat and simple, so I wanted to jump on that bandwagon, but... My first (and quite obvious) question was, "what happens if during the event processing a hardware node that