Banzai Cloud Logo Close
Home Products Benefits Blog Company Contact
Get Started
Almost every blog post or lecture explaining how Istio service meshes route traffic takes the time to go over how sidecar containers capture outgoing traffic - how that traffic is routed to another service with another sidecar. However, in the real world, a large amount of network traffic passes through the boundaries of the service mesh itself. That traffic might be from a public facing app that receives traffic from the internet, an internal service that needs to connect to a legacy application running outside the mesh, or a workload that consumes an external, third party API.
Read more...
In today's blogpost we're going to be discussing ingress and egress gateways. First, we'll cover the basics, then we'll go into detail and explore how they work through a series of practical examples. Ingress and egress gateways are load balancers that operate at the edges of any network receiving incoming or outgoing HTTP/TCP connections. Ingress gateways make it possible to define an entry points into an Istio mesh for all incoming traffic to flow through.
Read more...
The sidecar concept in Kubernetes is getting more and more popular, and for a good reason. In the container world, it's a common principle that a container should address a single concern only, but do it well. The sidecar pattern helps achieving this principle by decoupling the main business logic from supplementary tasks that extend the original functionality. In Kubernetes, a pod is a group of one or more containers with shared storage and network.
Read more...
One of the challenges we repeatedly faced when using microservices-based solutions was how best to properly secure communication between participating services. One option was to manage security at the application layer, which meant implementing specific authentication mechanisms in the application code itself. This approach, however, would quickly become burdensome, eating up time for developers, who should be concentrating on implementing actual business logic. Wouldn't it be awesome, we thought, if developers never had to worry about implementing authentication mechanisms in their application code, and, instead, there was a magical solution that would provide secure communication between their services?
Read more...
Today we are happy to announce the 1.1 release of Backyards, Banzai Cloud's automated and operationalized service mesh product built on Istio. This is an announcement post describing the new features of Backyards. If you're not familiar with Backyards yet, and want to know why we decided to build this product, we suggest reading the blog post about the first major release. Check out Backyards in action on your own clusters: curl https://getbackyards.
Read more...
In Kubernetes clusters, the number of Operators and their managed CRDs is constantly increasing. As the complexity of these systems grows, so does the demand for competent user interfaces and flexible APIs. At Banzai Cloud we write lots of operators (e.g. Vault, Istio, Logging, Kafka, HPA, etc) and we believe that whatever system you're working with, whether it's a service mesh, a distributed logging system or a centralized message broker operated through CRDs, you will eventually find yourself in need of enhanced observability and more flexible management capabilities.
Read more...
Two months ago we announced the release of Backyards, Banzai Cloud's multi- and hybrid-cloud enabled service mesh built on top of our Istio operator. One of Backyards’ hallmarks is its ability to simplify building a production-ready Istio deployment down to a single command: backyards install -a - complete with enterprise grade security, monitoring, tracing, logs, audit, and features like canary releases, traffic management, circuit breaking and lots more, either through a convenient UI, CLI or a GraphQL API.
Read more...
A while ago we published some benchmarks and sizing about our experience of running Apache Kafka over a service mesh with the Banzai Cloud Kafka and Istio operator, orchestrated by our automated and operationalized service mesh, Backyards. The reasons for such a setup were many, and there are more details in the Running Apache Kafka over Istio - benchmark post, but let me recap some of our initial reasons, and how we evolved from there.
Read more...
When someone first hears about Istio's sidecar concept, the first two questions are usually about its effect on resource consumption and request latency or throughput. In this post we'll discuss the first of those questions: resource consumption of Istio proxies and how it can be reduced with the new Sidecar custom resource. Previously we had a Kafka on Istio benchmark post that was about throughput, and we'll take a deeper look at the most important HTTP request metrics in a forthcoming article (stay tuned).
Read more...
Check out Backyards in action on your own clusters: curl https://getbackyards.sh | sh && backyards install -a --run-demo What to know more? Get in touch with us, schedule a demo or delve into the details of the latest release. Istio has been rightfully praised for ushering in free observability and secure service to service communication. Other, more significant features, however, are what truly make Istio the Swiss army knife of service mesh operators; when it comes to meeting SLOs like uptime, latency and error rates, the ability to manage traffic between services is absolutely critical.
Read more...