Today on Day Two Cloud we examine Istio Ambient Mesh, a new option for building service meshes in a microservices environment. Istio Ambient Mesh essentially brings the concept of a load balancer to a cluster of containers. Rather than run a sidecar proxy for each pod or container, you can run Ambient Mesh per node. Our guest and guide to this open source project is Christian Posta, Global Field CTO at Solo.io.
The post Day Two Cloud 173: Istio Ambient Mesh Minimizes Sidecar Proxies appeared first on Packet Pushers.

This post is also available in Français, 日本語, 简体中文, 한국어, Español.

At Cloudflare, we have strived to build a workplace where our entire team feels safe and excited to bring their whole selves to work, so they can do their best work. That’s why we are proud to share that Cloudflare has been named one of the Top 100 Most Loved Workplaces in 2022 by Newsweek and Best Practice Institute (BPI). Most Loved Workplaces recognizes companies where their workers love, and feel in sync with, the company they work for.
With this, and as we’re approaching the end-of 2022, we thought this was a good time to reflect on some of the things that go into being one of these Most Loved Workplaces and just some of what makes up our workplace and culture.

Something that really grounds our entire team is Cloudflare’s mission: to help build a better Internet. When you are solving some of the toughest challenges facing the Internet — helping make the Internet secure, fast, private, and reliable globally — you need a range of talented individuals to do this. The people at Cloudflare are exactly that, and are essential to our Continue reading
Imagine you built a layer-2 fabric with tons of VLANs stretched all over the place. Now the users want to exchange traffic between those VLANs, and the obvious question is: which devices should do layer-2 forwarding (bridging) and which ones should do layer-3 forwarding (routing)?
There are four typical designs you can use to solve that challenge:
This blog post is an overview of the design models; we’ll cover each design in a separate blog post.
Imagine you built a layer-2 fabric with tons of VLANs stretched all over the place. Now the users want to exchange traffic between those VLANs, and the obvious question is: which devices should do layer-2 forwarding (bridging) and which ones should do layer-3 forwarding (routing)?
There are four typical designs you can use to solve that challenge:
This blog post is an overview of the design models; we’ll cover each design in a separate blog post.
Are there angles on future metaverse that make sensee ? Johna and Greg dive into their perspectives on what is a metaverse and converge on the face that its a form of collaboration. Potentially it could be immersive with VR googles but more likely it’s about engaging data from external domains into the collaboration experience.
The post Heavy Strategy 037 – Metaversing The Office is More Than One Thing appeared first on Packet Pushers.
Kubernetes has come of age with more organizations adopting a microservices architecture at scale. But scale brings a whole slew of new challenges, especially with Kubernetes, which is designed to operate as a single cluster. However, the usage of Kubernetes, especially at leading-edge organizations operating at scale, has crossed the single-cluster threshold. Organizations are building and deploying services across multiple clusters for high availability, disaster recovery, application isolation, compliance, latency concerns, staged migration, and multi-tenancy reasons.
Regardless of the reasons to deploy multiple clusters, platform and application teams must address networking, security, and observability issues related to microservices deployed across multi-clusters, sometimes spanning hybrid and multi-cloud environments.
Calico, the most widely adopted container networking and security solution (according to a recently published container adoption report by Datadog), provides an operationally simple solution to solve the networking, security, and observability challenges of running multi-cluster Kubernetes environments.
In simple terms, creating a multi-cluster Kubernetes environment requires stitching multiple Kubernetes clusters together to provide a common set of services. To create a single logical environment spanning multiple clusters, the key requirements are:
Antti Ristimäki left an interesting comment on Network Automation Considered Harmful blog post detailing why it’s suboptimal to run manually-configured modern service provider network.
I really don’t see how a network any larger and more complex than a small and simple enterprise or campus network can be developed and engineered in a consistent manner without full automation. At least routing intensive networks might have very complex configurations related to e.g. routing policies and it would be next to impossible to configure them manually, at least without errors and in a consistent way.
Antti Ristimäki left an interesting comment on Network Automation Considered Harmful blog post detailing why it’s suboptimal to run manually-configured modern service provider network.
I really don’t see how a network any larger and more complex than a small and simple enterprise or campus network can be developed and engineered in a consistent manner without full automation. At least routing intensive networks might have very complex configurations related to e.g. routing policies and it would be next to impossible to configure them manually, at least without errors and in a consistent way.
What I’ve covered in the previous blog post about CUE and Ansible were isolated use cases, disconnected islands in the sea of network automation. The idea behind that was to simplify the introduction of CUE into existing network automation workflows. However, this does not mean CUE is limited to those use cases and, in fact, CUE is most powerful when it’s used end-to-end — both to generate device configurations and to orchestrate interactions with external systems. In this post, I’m going to demonstrate how to use CUE for advanced network automation workflows involving fetching information from an external device inventory management system, using it to build complex hierarchical configuration values and, finally, generating and pushing intended configurations to remote network devices.
CUE was designed to be a simple, scalable and robust configuration language. This is why it includes type checking, schema and constraints validation as first-class constructs. There are some design decisions, like the lack of inheritance or value overrides, that may take new users by surprise, however over time it becomes clear that they make the language simpler and more readable. One of the most interesting features of CUE, though, is that all code Continue reading
We are excited to announce an updated version of the NSX Reference Design and the NSX Easy Adoption Design guide based on the generally available NSX-T release 3.2. NSX-T 3.2 is part of the recently released VCF 4.5 software bundle, making it a very popular release among our customers.
To support you in your network and security virtualization journey, we introduced the NSX-T reference architecture design guide on the NSX-T 2.0 release, showing how you should design your data centers with NSX-T. Over time we introduced additional design guides such as the NSX-T Multi-Location Design Guide (Federation + Multisite), the Easy Adoption Design guide, and the NSX-T Data Center and EUC Design Guide for more specific use cases.
These latest updates cover the new features included in the 3.2 versions and the design and implementation guidelines we developed working tightly with our customers on their NSX projects.
This document is the most essential document for any NSX practitioner. Whether you are just starting with NSX or have already successfully implemented NSX in your environment, the NSX Reference Design guide provides a clear and detailed description Continue reading