I had initially intended to write about some personal highlights of Kubecon 2019, so I scribbled down a list of the projects that seriously expanded my view of what was possible. But since I’ve been sitting on this for quite some time I figured I might as well add some 2020 hindsight and take this opportunity to compare my initial reactions and current feelings about these projects.

Please note the key word there: feeling. Unless otherwise mentioned these comments are not backed by hands-on experience.

Overall Kubecon NA 2019 was quite a special experience for me. I think a number of contributing factors created a positive feedback loop that amplified the whole experience. Specifically:

• My mental state and level of experiece at my then-current job
• The awesome co-workers and friends that I shared it with
• It was my first jumbo-sized remote conference
• I received my next job offer during the conference

Now add the amazing stories and tech that are par for the course at every Kubecon and you end up with a recipe for an impactful experience. Thinking about it even now over a year later I am filled with gratitude to have been part of the experience.

OPA (Open Policy Agent)

Initial Thoughts

Not really sure about the implementation particulars but writing enforcing policies in a DSL (rego) and applying them to incoming resources via the Gatekeeper component feels powerful. While I don’t think I can use it right now because of where we are in our journey, I’m definitely going to keep track of this project and fit it into our workflow where it makese sense.

Retrospective

While I generally still feel the same way and unfortunately haven’t had much hands-on time with the project, OPA and rego have a much broader utility than just for enforcing policy in K8s clusters via mutating and verifying admission webhooks. This is a general purpose policy verification framework

NATS

Initial Thoughts

Similar to Kafka, but some of the failover and multicluster aspects are impressive (especially in a live demo!). We’re using Kafka now, and compared to Kafka NATS is lacking in the resilience department so I probably won’t use NATS much if at all.

Retrospective

I was looking at NATS primarily through the lens of a Kafka replacement, having just spent a fair amount of time working with Kafka. I haven’t seen or heard of any NATS deployments used in that manner (but I admit I haven’t been looking much, either), but where I have seen it shine is as an embedded message bus in Argo Events .

Argo Events uses NATS as a common internal communication layer to pass events between various upstream external event sources and downstream external event triggers. NATS is lightweight, self-contained, and resilient enough to fit as an embedded subsystem where something heavier like Kafka just doesn’t make sense.

Linkerd vs Envoy

Initial Thoughts

Both projects look like they provide significant power and functionality but I keep seeing cases where Linkerd is leaner, faster, and simpler to operate. I know that Envoy is more than just the main proxy component in Istio and so it’s not a completely equal comparison, but right now that’s the place where I’m seeing it used the most. Frankly Istio’s complexity freaks me the deek out and in comparison Linkerd looks like the way to go for a kubernetes service mesh.

Retrospective

Although I’m not as bearish about Envoy’s performance, I feel mostly the same that Linkerd would be the best bet for a service mesh solution on a greenfield Kubernetes-only deployment. However I have recently been looking at a brownfield VM to Kubernetes migration where subcomponents would be moved to Kubernetes one at a time, straddling both VMs and Kubernetes for the duration of the migration.

That being the case Linkerd just won’t work so I’ve been looking at other solutions like Consul and Kuma that may better fit our requirements. Honestly though, as I’ve used more Envoy-based products (Contour, Gloo, Envoy itself) and gained more experience with it my perception has grown to be much more positive than in 2019. Linkerd is still an impressive product but as time has passed it has become clear that Envoy is the standard to compare other solutions against for a reason.

Pulsar

Initial Thoughts

Oh. My. Freaking. God. Pulsar is baller. Decoupling the compute and storage requirements across different tiers means you can add or lose brokers as your load requires and can scale storage independently as you need to without manually shuffling data around. All that and it has (supposedly) consistently lower latency than Kafka, builtin multi-tenancy, and S3 offload capability? Sign me up!

Retrospective

I’ve kept track of the Pulsar project since 2019 and by perspective has not changed. If anything I am more impressed now than I was then. Specifically the Pulsar functions serverless framework, KOP (Kafka on Pulsar) compatibility layer, and consistent hashing on keyed subscriptions are most interesting.

Unfortunately I still haven’t had an opportunity to put Pulsar through its paces, much less in a production capacity. But it is such an exciting project, I keep looking for a place that it will fit.