howardjohn's Blog

Gloo Mesh’s ambient multi-cluster mode sets a new benchmark for scalability.

Go 1.24 introduces new support for "Tools", which allows easy consumption of tools (which are written in Go) as a dependency for a project. This could be anything from golangci-lint to protoc-gen-go. In this post, I will cover usage and limitations. Basic usage Adding a tool to a project is nearly the same as a standard runtime dependency, with the additional -tool flag: $ goimports # I don't have goimports yet! zsh: command not found: goimports $ go get -tool golang.org/x/tools/cmd/goimports go: added golang.org/x/mod v0.22.0 go: added golang.org/x/sync v0.10.0 go: added golang.org/x/tools v0.29.0 $ go tool goimports --help usage: goimports [flags] [path ...] Once we add a tool, we can access it by go tool <name>. ...

Is it a per-node proxy? Is it a sidecar? The reality is somewhere in between

Reimagine service mesh with Istio’s ambient mode—lightweight, efficient, and scalable. Gloo Mesh now extends this innovation to multi-cluster environments, delivering unmatched reliability, simplicity, and scale.

A deep dive into the termination behavior of Istio ambient mode and how it impacts your applications.

How Istio ambient mode brings an enterprise-ready service mesh to Amazon ECS.

How ambient achieves massive scale without toil.

When we first started designing what eventually became Istio ambient mode, there were many directions we explored, both in terms of implementation, and what our goals were. What resonated most, though, was that we wanted to provide an incredibly easy onboarding story for a subset of functionality. This subset, ultimately, was getting Mutual TLS deployed for all service-to-service communication within a cluster. I talk a bit more about this here. Since then, I think we have delivered on this promise... and gone even further! In this post, I wanted to highlight some of the areas that I think ambient helps deliver some serious value to users with minimal complexity. ...

Over 2 years ago, I started working on some ideas to build better Kubernetes controllers. In this post, I wanted to give a bit of a retrospective on how things have gone since then. Over the years working on Istio and other projects, I observed a number of major issues with controllers: Most code was about error-prone event handling and state reconciliation, rather than business logic. Most tests, in turn, were about the same. This, in turn, made the code extremely complex, brittle, and often incorrect. This complexity lead to user facing compromise: incorrectness and performance issues. You might argue I should just write a better controller that is faster and without bugs. Maybe, but probably not. ...

External Blog Post.