Keep up with the latest from us
Tetrate is excited to announce and welcome Brian Dussault to the team! Brian is joining as the Head of Engineering. He will lead and scale the Engineering organization owning TSB and open source initiatives that offer rich and highly performant solutions empowering multiple personas across the enterprise in their Service Mesh journey.
If you’ve been watching the service mesh space recently, you’ll have noticed a lot of talk about eBPF and “sidecar-less” meshes. In fact, there’s been so much talk about these things that I’m hoping for a lot of readers for this blog post, just because I’ve got all of it in the title!
But what actually are “sidecar-less” service meshes? How do they work? And do they solve the problems we’ve been told they do, namely improving performance and reducing resource usage? In this post I’ll explain what these two technologies are, what they can and can’t do for the mesh, and how they do — and do not — work together.
Introducing performance analysis in production with SkyWalking Rover.
Apache SkyWalking observes metrics, logs, traces, and events for services deployed into the service mesh. When troubleshooting, SkyWalking error analysis can be an invaluable tool helping to pinpoint where an error occurred. However, performance problems are more difficult: It’s often impossible to locate the root cause of performance problems with pre-existing observation data. To move beyond the status quo, dynamic debugging and troubleshooting are essential service performance tools. In this article, we’ll discuss how to use eBPF technology to improve the profiling feature in SkyWalking and analyze the performance impact in the service mesh.
Service mesh is an infrastructure layer between application components and the network via a proxy. These app components are often microservices, but any workload from serverless containers to traditional n-tier applications in VMs or on bare metal can participate in a mesh. Rather than each component communicating directly with other components over the network, the proxies mediate that communication. These proxies form the data plane, providing many capabilities for implementing security and traffic policy and producing telemetry about the services the proxies are deployed with. Read more about service mesh capabilities.
One of the core ideas that motivates the zero trust architecture is the idea that “the attacker is already in the network.” Many of the projects, tools, and techniques we see gaining widespread adoption today for enabling a zero trust architecture were born out of companies that know this first-hand. One seminal event was the Snowden leaks in 2011, which prompted Google to adopt encryption in transit for all communications, even over their own internal network.
One of the strengths of Kubernetes is its flexibility in terms of the target infrastructure on which it can be deployed. It can be rolled out on anything from a tiny cluster running on a laptop to large, multi-national scale-out infrastructure. Applications that run on such scaled-out infrastructure often require support for multiple clusters, regions, and even multiple cloud providers. Among our enterprise customers, we also see a trend of migrating from monolithic architectures for their applications to microservices.
More and more organizations today use microservices and distributed architectures to achieve agility and scale; the most recent CNCF survey, for example, finds that more than 50% of organizations are using Kubernetes in production. At the same time, we’re seeing a growing number (including most of our customers), adopting a multi-cloud strategy – due to changing business needs. Enterprises now require the ability to allow different parts of the organization to use best-in-class functionality for their use cases, or an acquisition driven business model. They deploy their applications into the public cloud (Google, Amazon, Azure, etc.) as well as on-premises, including both Kubernetes and virtual machine-based workloads.
Istio 1.14 was released in June of this year, and one of the most notable features of this release is support for SPIRE, which is one of the implementations of SPIFFE, a CNCF incubation project. This article explains what SPIRE means for zero-trust architectures and why you would need SPIRE for authentication in Istio.
An Istio Egress gateway is just another envoy instance similar to the Ingress but with the purpose to control outbound traffic. Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.
This is the second installment in a two-part series on NIST standards for zero trust security. The first installment covers NIST Special Publication (SP) 800-207, which lays the groundwork for zero trust principles for the enterprise, but makes no specific implementation recommendations.
The follow-up series is made up of four special publications: SP 800-204, SP 800-204A, 800-204B, and 800-204C. This series is co-authored with NIST by Tetrate founding engineer Zack Butcher and takes up where SP 800-207 leaves off.
This series provides security strategies for microservices applications. It mostly focuses on communications between services and between services and a control plane, as described below, under the header Threat Background. In this article, we’ll present an overview of the most important concepts, best practices, and specific deployment recommendations in each of the four papers of the SP 800-204 series:
