The Istio “ambient mesh” branch was recently merged to main. This marks a major milestone for ambient, and offers new choices for Istio users. In this post, I want to add some clarity to the broader discussion of Istio deployment topologies, and also set out Tetrate’s views on ambient and Istio going forwards.
WebAssembly, also known as Wasm, is a way to compile code written in one programming language, such as C or Rust, and run it on a different runtime, such as in a web browser or microservice. This makes it a great choice for writing plug-ins, extensions and, in general, running user-defined arbitrary code in a safe, sandboxed environment.
WebAssembly is often mistaken for a technology that is only used in the browser when, really, Wasm is a cross-platform binary that can be executed by any WebAssembly runtime. Historically, there were not many good options for Go programmers, but this has changed.
This post introduces wazero, why it matters for infrastructure written in the Go programming language, and covers its most compelling features.
One of the things we’re asked about by our customers adopting a service mesh practice is how Open Policy Agent (OPA) and service mesh fit together and interact in their application infrastructure. In this article, we’d like to weigh in with some thoughts on where service mesh and OPA policy are best suited, respectively, and how they complement each other.
Four months after the first public release of Envoy Gateway (EG), we’re very pleased to announce the immediate availability of version 0.3. This latest release is the culmination of hard work by several Tetrands, along with others from across the community. Envoy Gateway now supports the entire Kubernetes Gateway API, including the experimental parts—adding some powerful new features and moving this free open-source software ever-closer to being a fully-featured API Gateway.
This article is part of a three-part series on Istio’s development, how to optimize Istio performance (this article), and Istio’s open source ecosystem and its future.
After Istio’s architecture stabilized in version 1.5 (March 2020), as mentioned in the previous article, the community’s main focus turned to optimizing performance. In the following sections, we’ll look at the different optimization methods that were considered by Istio and describe which approaches were adopted.
This is the first in a series of three articles that reviews the development of the Istio open-source project (this article), shows how to optimize Istio performance, and describes Istio’s open-source ecosystem and future. I also share my view on the most appropriate use of eBPF with Istio, mostly in the second article.
Service mesh technology is on the rise due to the popularity of Kubernetes container management software, the use of microservices and the DevOps approach in application development and delivery, and the growing use of cloud native architectures. Istio is the leading service mesh software, nearly always implemented with Envoy as a sidecar proxy.
The rise of Kubernetes and programmable data proxies such as Envoy proxy create the foundation for Istio. The future of Istio is to further serve as the foundation for a secure, zero-trust network.
This is the third in a series of service mesh best practices articles excerpted from Tetrate’s forthcoming book, Istio in Production, by Tetrate founding engineer Zack Butcher.
Istio is like a set of Legos: it has many capabilities that can be assembled just about any way you want. The structure that emerges is based on how you assemble the parts. In the previous installment of this blog series, we described an opinionated runtime topology to build a robust, resilient, and reliable infrastructure. In this article, we’ll describe an opinionated set of mesh configurations to help achieve robustness, resiliency, reliability, and security at runtime.
This is the second in a series of service mesh best practices articles excerpted from Tetrate’s forthcoming book, Istio in Production, by Tetrate founding engineer Zack Butcher.
There are a few moving pieces when it comes to a service mesh deployment in a real infrastructure across many clusters. The primary pieces we want to highlight here are how control planes should be deployed near applications, how ingresses should be deployed to facilitate safety and agility, how to facilitate cross-cluster load balancing using Envoy, and what certificates should look like inside the mesh.
Federal information systems need FedRAMP approval for authority to operate. To get that approval, they must comply with the Federal Information Processing Standards (FIPS). For cryptography, this means that if you’re a U.S. government agency or a vendor or contractor supplying the government, you must use FIPS 140-2 compliant modules wherever encryption is required. If you want to use Istio or Envoy in those systems, you can’t use the stock community builds of Istio and Envoy, since they don’t use FIPS-compliant cryptography modules and are thus not suitable for a FedRAMP environment.
Tetrate enables government organizations to meet this requirement by supplying Istio users with the first FIPS-verified open source distribution of Istio and Envoy as part of Tetrate’s hardened and performant Tetrate Istio Distro.
In this article we will lay out the basics of FIPS compliance, what it means for Istio and Envoy, and the surest way to get to production with Istio in a FIPS-regulated environment.
To find out more about FIPS and Istio, download our free Primer on Zero Trust and FIPS for Cloud Native Applications.
In the previous blog post, I introduced how Istio manages certificates, and in this article, I will guide you on how to use an external certificate authority (CA) to achieve fine-grained certificate management and automatic certificate rotation through the integration of SPIRE and cert-manager.
