Andrew Green, Author at Gigaom

GigaOm Radar for Network Observability

Andrew Green — Fri, 17 May 2024 15:00:25 +0000

Network observability is a category of solutions that go beyond device-centric network monitoring to provide truly relevant end-to-end visibility and intelligence for all the traffic in your network, whether on-premises, in the cloud, or anywhere else. Representing a step beyond network performance monitoring, network observability guarantees visibility and distinguishes itself with actionable insights. These insights shift many low-level activities—such as troubleshooting or traffic analysis—from engineers to the network observability tool.

Observability solutions are less about specialization and more about consolidating a comprehensive experience in a single tool. This convergence of functionality brings numerous advantages, including a better user experience, lower costs than those incurred when deploying multiple tools, adaptability for complex IT environments, future-proofing, and cohesiveness across IT departments. Network observability is a key ingredient for ensuring that your modern, critical infrastructure achieves the required uptime and availability.

While businesses of all sizes can benefit from the end-to-end visibility offered by network observability solutions, those with large, complex networks are likely to see the most improvement. These can be companies with proprietary networks, for which IT plays a supporting role—such as retail or manufacturing—or businesses that sell network services, such as communication service providers. We explore these categories in more depth in the following section.

This is our fourth year evaluating the network observability space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Radar report examines 20 of the top network observability solutions in the market, and compares offerings against the capabilities (table stakes, key features, and emerging features) and non-functional requirements (business criteria) outlined in the companion Key Criteria report. Together, these reports provide an overview of the category and its underlying technology, identify leading network observability offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The GigaOm Key Criteria report provides a detailed decision framework for IT and executive leadership assessing enterprise technologies. Each report defines relevant functional and nonfunctional aspects of solutions in a sector. The Key Criteria report informs the GigaOm Radar report, which provides a forward-looking assessment of vendor solutions in the sector.

The post GigaOm Radar for Network Observability appeared first on Gigaom.

GigaOm Key Criteria for Evaluating Full-Stack Edge Deployment Solutions

Andrew Green — Wed, 15 May 2024 15:29:19 +0000

Full-stack edge deployments are cloud-managed and cloud-connected software-defined hyperconverged solutions that provide all the tools for running applications at customers’ preferred locations for local data collection and processing.

These solutions bring a cloud-like experience to edge or on-premises locations, enabling customers to run applications locally, and collect, process, and analyze data there. This scenario can support latency-sensitive use cases for real-time application, operate in air-gapped scenarios, and minimize cloud data transfers, resulting in lower costs and simpler cloud architectures.

These solutions operate on top of converged infrastructure, which packages compute, storage, and networking into a single appliance. Such appliances can be deployed in remote industrial locations, such as retail stores where IT support is limited, or even in on-premises data centers. Because the solutions operate on top of converged infrastructure, customers do not need to invest in architecting the infrastructure stack, such as by defining network connectivity between different elements, or by dealing with heterogeneous appliances and their proprietary management consoles.

To further support this reliance on converged infrastructure, full-stack edge deployments aim to deliver plug-and-play solutions, enabling appliances to be fully provisioned on being plugged in and connected to the internet. The solution can then download a set of configuration files and prepackaged images containing services and development environments.

To support a cloud-like experience, full-stack edge deployments enable administrators to provision resources and services such as compute instances (virtual machines or VMs, containers), storage services (data lakes, object storage), networking constructs (routers, NAT), and security (firewalls, antiviruses).

With the infrastructure component of the IT stack in place these solutions can also deliver services such as load balancers, databases, managed Kubernetes, and even a collection of AI models.

Further, these solutions can integrate with public cloud providers to send and receive data from cloud environments, logically group applications running on the full-stack edge deployment with public cloud applications and services, orchestrate public cloud services from the same management console, and set up backup and disaster recovery to cloud-based services.

Multiple deployments can be clustered and managed together so that geographically distributed systems can have configurations pushed to them simultaneously and consistent applications and policies can be defined across all deployments.

Business Imperative
These solutions tackle the challenges not addressed with traditional on-premises IT hardware-software stacks or with cloud environments. By bringing the developer-friendly centralized management way of the cloud to edge devices, organizations can benefit from a streamlined deployment and management experience. Large and geographically distributed environments are set to benefit the most from centralizing and automating applications that run at the edge.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of a full-stack edge deployment solution to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a full-stack edge deployment solution, we provide an overall Sector Adoption Score (Figure 1) of 3.6 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that a full-stack edge deployment solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for full-stack edge deployment are explained in more detail in the Sector Brief section that follows.

Key Criteria for Evaluating Full-Stack Edge Deployment Solutions

Sector Adoption Score

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Figure 1. Sector Adoption Score for Full-Stack Edge Deployment

This is the first year that GigaOm has reported on the full-stack edge deployment space in the context of our Key Criteria and Radar reports. This GigaOm Key Criteria report highlights the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) for selecting an effective full-stack edge deployment solution. The companion GigaOm Radar report identifies vendors and products that excel in those decision criteria. Together, these reports provide an overview of the market, identify leading full-stack edge deployment offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The post GigaOm Key Criteria for Evaluating Full-Stack Edge Deployment Solutions appeared first on Gigaom.

There’s Nothing Micro About Microsegmentation

Andrew Green — Wed, 15 May 2024 13:11:23 +0000

I began my exploration of the microsegmentation space by semantically deconstructing the title. The result? Microsegmentation solutions help define network segments as small as a single entity. While I believe this is a useful approach to intuitively understand the technology, my couple hundred hours of research revealed that the scope for microsegmentation is enormous. It is so large that I have to invalidate the initial “single-entity network segment” definition to capture the technology as exhaustively as possible. This means that microsegmentation is not a single-entity exercise, and it’s not defined only using network constructs.

Microsegmentation is a Multiple-Entity Construct

In absolute terms, when you define a microsegment, you dictate the policies applied to a single entity, such that it allows some traffic or requests while blocking others. However, traffic always flows between two entities, so both endpoints must be considered.

On one end, you have the entity you want to isolate—let’s say a container. On the other, you have all the other entities that will communicate with the container you want to isolate. It’s worth noting that these requests are likely bidirectional, but for the sake of simplicity, we will assume ingress traffic only.

When looking to isolate a container, sophisticated policies (other than allow/block) need to consider requests from a wide range of entities, which include other containers, virtual machines, developers and administrators, function as a service (FaaS)-based microservices, external APIs, monolithic applications, IoT devices, and OT devices.

The underlying technologies that can define policies between containers and all these other types of entities include container networking interfaces for container-to-container communication, service meshes for service-to-container communication, ingress controllers for cloud or data center workload-to-container communication, secure shell for administrator-to-container communication, and so on.

It quickly becomes obvious that defining these policies involves a lot of components that span across disciplines. Some solutions choose to deploy agents as a single point for managing policies, but organizations increasingly favor agentless solutions.

When working with a microsegmentation solution, the day-to-day activities of defining and managing these policies will not involve directly working with all these technologies because they abstract all these aspects and provide an intuitive GUI.

The reason I am highlighting this is to evaluate a solution. Depending on the types of assets you need protected, the supported entities are by far the most important evaluation aspect. If you want to protect IoT devices, but a solution does not support that, it should be immediately excluded.

Microsegmentation is Not Just Network-Based

Those with a networking background, myself included, borrow the segmentation concept from firewall-defined network segments. It’s both useful and relevant, and you can see this concept being carried over in distributed firewall solutions provided by the likes of Aviatrix, VMware, and Nutanix.

But there are two more ways of isolating entities besides using network constructs:

Using identity-based policy enforcement. This offers controls that are independent of network constructs such as IPs. Access can be governed using attributes such as operating system type, patch status, VM name, Active Directory groups, and cloud-native identities like labels, tags, and namespaces. Solutions can also assign labels or categorize entities natively to remove dependencies on third-party labeling systems.
Using process-based policy enforcement. For example, the microsegmentation solutions can monitor the running processes on every entity, capturing detailed context for each process and its associated libraries. Process and library hashes can be assessed against a threat data feed to identify malicious code execution and detect variation from known good processes. Processes can include applications, services, daemons, or scripts, and details such as process name, path, arguments, user context, and parent processes. If a malicious process is detected, the entity is then isolated from communicating with the rest of the network.

At the end of the day, you can’t cut off communications without involving the network, but the microsegmentation policy itself does not have to be dependent on networking constructs, such as 5-tuples.

Next Steps

When evaluating microsegmentation solutions, I recommend you approach them as highly sophisticated designers of security policies. Most often, an entity can be isolated just by blocking ports. So, the effectiveness of the solution will depend on whether it can support all the entities you need to protect and how easy it is to manage all the policy permutations.

To learn more, take a look at GigaOm’s microsegmentation Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post There’s Nothing Micro About Microsegmentation appeared first on Gigaom.

GigaOm Key Criteria for Evaluating Network Observability Solutions

Andrew Green — Wed, 24 Apr 2024 17:04:51 +0000

Network observability is a category of tools that goes beyond device-centric network monitoring to provide truly relevant, end-to-end visibility into and intelligence about all traffic traveling across your network. These tools provide comprehensive visibility whether your network infrastructure is on-premises, in the cloud, or anywhere else.

Network observability is a next-generation technology that stems from traditional monitoring and management. Instead of revolutionizing traditional network monitoring, network observability focuses on incremental developments and maturity. Leveraging developments from other areas of technology—such as machine learning (ML), AI operations (AIOps), and infrastructure as code (IaC)—network observability moves toward an automated and intelligent way of maintaining high-performance and low-cost network operations.

Between a lack of actionable insights available and limited interoperability among systems, network operations teams historically have had to conduct manual processes for root cause analysis (RCA), exporting data into spreadsheets for visualization, and checking for performance degradations and correlations.

These manual processes became even more complex as enterprises underwent cloud transformations—the most significant change to network infrastructure in the past decade. Organizations have migrated away from on-premises environments with a few devices hosted in co-location data centers to complex hybrid cloud environments. Network observability tools must monitor physical links and devices as well as virtual networking constructs and networking infrastructure delivered and managed by third-party suppliers.

Observability helps teams better deal with multiple environments, providing a high-level view of the network while picking up relevant details to extract actionable insights. Compared to network performance monitoring, network observability offers value from two perspectives:

Better use of IT resources: When the network can answer questions about itself, IT professionals no longer have to hunt for the right information, generate reports, or perform manual troubleshooting. Instead, they can leverage their skills and talents toward proactive decision-making and other higher-value activities.
Business-oriented IT results: Efficient monitoring and management can improve network optimization and ensure consistent network performance by enabling capacity planning, reducing mean time to recovery (MTTR), enabling RCA, and automating troubleshooting. Truly comprehensive observability can tie all of these results back to business objectives and provide meaningful insight directly to all stakeholders, not just technical staff.

Business Imperative
Modern network observability tools are indispensable for all businesses, regardless of whether these organizations own and manage their own networks. Even cloud-native startups can benefit from network observability tools because the domain-specific features can offer insights that other cloud-native tools cannot.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of a network observability solution deployment to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a network observability solution, we provide an overall Sector Adoption Score (Figure 1) of 4.2 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that a network observability solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for network observability are explained in more detail in the Sector Brief section that follows.

Key Criteria for Network Observability Solutions

Sector Adoption Score

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Figure 1. Sector Adoption Score for Network Observability

This is the fourth year that GigaOm has reported on the network observability space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Key Criteria report highlights the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) for selecting an effective network observability solution. The companion GigaOm Radar report identifies vendors and products that excel in those decision criteria. Together, these reports provide an overview of the market, identify leading network observability offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The post GigaOm Key Criteria for Evaluating Network Observability Solutions appeared first on Gigaom.

GigaOm Radar for Microsegmentation

Andrew Green — Tue, 16 Apr 2024 15:00:31 +0000

Microsegmentation solutions define and enforce per-entity communications policies. In this context, an entity can be any information technology (IT) or operational technology (OT) resource that processes and stores data. Entities can range from workloads hosted in the cloud to containers running in an on-premises data center, as well as OT systems, applications, services, and end-user devices. By defining policies for single entities, microsegmentation becomes a key technology for enforcing least privilege access.

While the concept of isolating individual entities is simple, two requirements of today’s microsegmentation solutions make them much more nuanced and complex:

Microsegmentation policies are always applicable to interaction between two entities: every entity is isolated from others, and depending on the identity of the “from” entity, policies will look different. For example, administrators may want to block all traffic from a category of workloads and only allow traffic on a specific port from others. If we’re isolating entity A, we need to consider the policies between A and B, A and C, and so on.
All entities are subject to microsegmentation. In heterogeneous environments, this makes microsegmentation exercises very complex because different underlying technologies require different types of policies. For example, the way containers communicate with each other is different from the way a developer accesses a server, so a solution supporting both instances must develop use case-specific features.

The scope for microsegmentation is enormous, and while all the vendors featured in this report offer microsegmentation capabilities, they employ different approaches. For example, some vendors have developed purpose-built microsegmentation products with an architecture that is applicable across as many use cases as feasible. Others have created purpose-built solutions that focus on specific goals. Other vendors offer solutions that are part of the networking and virtualization stack, and they enforce microsegmentation from that vantage point. For IT buyers, the decision criteria defined below are indicative rather than prescriptive about what a solution needs to support.

This is our first year evaluating the microsegmentation space in the context of our Key Criteria and Radar reports. This GigaOm Radar report examines 13 of the top microsegmentation solutions and compares offerings against the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) outlined in the companion Key Criteria report. Together, these reports provide an overview of the market, identify leading microsegmentation offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The post GigaOm Radar for Microsegmentation appeared first on Gigaom.

GigaOm Key Criteria for Evaluating Microsegmentation Solutions

Andrew Green — Tue, 26 Mar 2024 15:22:38 +0000

Microsegmentation solutions isolate single entities on networks by restricting inbound traffic, minimizing a malicious actor’s potential for lateral movement. A more efficient take compared to firewall-based network segmentation, microsegmentation provides administrators granular control over the allowed and restricted traffic at a workload level. This means they don’t need to define overly permissive policies to ensure all entities in a segment can be accessed.

Modern applications are distributed. They’re deployed both on-premises and in the cloud, or across multiple clouds, and critical workloads are no longer tidily kept in the data center where they can be protected by a perimeter firewall.

We use the term “entity” to describe any part of an IT environment that can process and store data. These can be virtual machines (VMs), servers, containers, cloud-based services, applications, end-user devices, and the like. Each entity type requires a different approach. For example, microsegmentation at a container level may have to be defined at the container networking interface level, either by running an agent in a sidecar container or by running an agent in the container image, whereas defining a microsegment for a VM may entail an agent running on the hypervisor or on the guest operating system.

Microsegmentation became its own category of solutions when enterprises experienced difficulties minimizing lateral movement and blast radius using firewall-based segmentation. Whether they’re physical or virtual, deploying, configuring, and maintaining firewalls is expensive and resource-intensive. Having a firewall isolate every entity or group of entities necessary is also excessive, especially when the required policies would be simple, such as blocking a port.

The lowest-hanging architectural fruit to replace firewall-based segmentation was to deploy firewall-like agents on the host. These agents provide very good granular control over the incoming and outgoing traffic, but they need to be individually managed and consume the host’s resources. As such, most solutions today have gravitated toward an agentless approach, by which solutions orchestrate existing infrastructure to enforce policies.

Business Imperative
Microsegmentation is a core component for any organization that wants to adopt a zero-trust security model. It is the defining technology that controls workload-to-workload policies, while also being suitable for user-to-workload use cases.

Microsegmentation assumes security breaches are imminent and encourages administrators to design a suite of preventative measures to minimize damage. Instead of creating very strong perimeters that, once breached, mean game over, microsegmentation assumes any entity can be compromised, but malicious actors have no possibility of accessing any other data or service.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of a microsegmentation solution deployment to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a microsegmentation solution, we provide an overall Sector Adoption Score (Figure 1) of 3.8 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that a microsegmentation solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for microsegmentation are explained in more detail in the Sector Brief section that follows.

Key Criteria for Evaluating Microsegmentation Solutions

Sector Adoption Score

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Figure 1. Sector Adoption Score for Microsegmentation

This is the first year that GigaOm has reported on the microsegmentation space in the context of our Key Criteria and Radar reports. This GigaOm Key Criteria report highlights the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) for selecting an effective microsegmentation solution. The companion GigaOm Radar report identifies vendors and products that excel in those capabilities and metrics. Together, these reports provide an overview of the market, identify leading microsegmentation offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The post GigaOm Key Criteria for Evaluating Microsegmentation Solutions appeared first on Gigaom.

The Cloud Networking Polysemy

Andrew Green — Fri, 22 Mar 2024 19:53:39 +0000

A very high market demand for cloud networking has encouraged a large number of networking vendors to enter this space. Each of them has been enforcing the perspective of their existing products onto a still loosely defined category, while all calling themselves “cloud networking providers.”

This creates a lot of confusion; at least it did for me. It’s a prime example of the anchoring bias, whereby I initially defaulted to the first definition of cloud networking that I came across.

In this blog, I’ll lay out all the versions of this technology that I’ve identified over the past three years to help buyers find the right solution for their business requirements instead of stumbling over semantics.

Different Approaches to Cloud Networking

Vendors can be categorized as follows:

Point-solution cloud networking providers: These primarily tackle multiple public cloud connectivity in a SaaS format or using only virtual networking appliances and have expanded to hybrid cloud use cases. Vendor examples include Aviatrix and Prosimo. Some vendors such as Alkira and F5 fall into this category and another at the same time, as they are also network-as-a-service (NaaS) providers. Arrcus also provides data center networking.
Data center networking vendors: These vendors have expanded their portfolio of data center networking products to include cloud environments, and they include Cisco, Arista, Juniper, and VMware by Broadcom.
NaaS providers: These vendors are focused on on-premises to cloud connectivity using private network backbones but do not define networking constructs within the public cloud. Some examples are Packetfabric, Perimeter 81 (acquired by CheckPoint), Aryaka, and Graphiant.
Cloud-native networking: With only one representative vendor so far, Isovalent (acquired by Cisco) developed the Cilium CNI, which is widely adopted and used as part of the container infrastructure stack in major public cloud providers.
Cloud networking services: Also encountered as “cloud networking solutions” in the wild, these are professional services that likely use one, two or multiple technologies from those named above to help organizations define their networks. Vendor examples include Kyndryl, Epsilontel, and Orange Business Services.

In their most basic forms, all of these takes on cloud networking can be used for the following use cases: networking inside the public cloud, networking between on-premises and public clouds, networking native to the public cloud as part of the infrastructure stack, cloud networking professional services, and networking in the data center that extends to the public cloud.

Which is the Best Approach?

Firstly, none of these approaches or definitions are wrong. Likewise, employing the same “cloud networking” term to describe multiple approaches isn’t an issue either. The problem arises when:

Buyers are not aware of this ambiguity. Navigating polysemantic terms or acronyms is only possible if you’re aware of them. For example, we may distinguish between SME as meaning “subject matter expert” and “small-to-medium enterprise” from context, but only if we’re familiar with both.
Vendors themselves are not aware of this polysemy. Or they choose to ignore it. Those with well-thought out and well-written definitions and marketing collateral will help combat rather than add to the confusion.

The market ended up in this situation because a range of different vendors were solving similar yet different customer problems, and they all used the same label when advertising their solution. While third parties can do their best to guide buyers navigating new markets, they too are subject to vendors’ messaging. That’s why I believe that the power of establishing clarity originally lies with the vendors and their technical marketing departments.

Before beginning their search, I recommend that prospective customers reference the list above that is applied across today’s vendor landscape. A vendor-based approach is much more useful because engagements with vendors whose profile and use cases don’t fit your organization’s needs will most likely be unproductive.

Next Steps

To learn more, take a look at GigaOm’s Cloud Networking Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post The Cloud Networking Polysemy appeared first on Gigaom.

The Elephant Flows Through the Data Center Network

Andrew Green — Thu, 21 Mar 2024 21:38:58 +0000

Techniques for optimizing data center networks to support AI workloads are not intuitive. You first need a baseline understanding of how AI workloads behave in the data center and how that’s different from non-AI or traditional workloads.

In this blog, we’ll explore how AI workloads behave in the data center and which networking features support this use case. We’ll start with some axiomatic one-liners, followed by more in-depth explanations of more complex processes—graphical processing unit (GPU) clustering, synchronicity, tolerance, subscription architectures, and knock-on effects. Lastly, we’ll describe features that data center switching solutions can offer to support organizations that are developing and deploying AI applications.

AI Traffic Patterns in Data Center Networks

The Basics

To form a baseline for understanding AI traffic patterns in data center networks, let’s consider the following postulates:

The most computationally intensive (and implicitly, network-heavy) phase of AI applications is the training phase. This is where data center network optimization must focus.
AI data centers are dedicated. You don’t run other applications on the same infrastructure.
During the training phase, all traffic is east-west.
Leaf-spine is still the most suitable architecture.

More Complex Processes

GPU Clustering
In most cases today, AI is trained on clusters of GPUs. This helps break up large data sets across GPU servers, each handling a subset. Once a cluster is finished processing a batch of data, it sends all the output in a single burst to the next cluster. These large bursts of data are dubbed “elephant flows,” which means that network utilization nears 100% when data is transmitted. These fabrics of GPU clusters connect to the network with very high bandwidth network interface controllers (NICs), ranging from 200 Gbps up to 800 Gbps.

Synchronicity
Asynchronous workloads are common in non-AI workloads, such as end-users making database queries or requests of a web server, and are fulfilled upon request. AI workloads are synchronous, which means that the clusters of GPUs must receive all the data before they can start their own job. Output from previous steps like gradients, model parameters, and so on become vital inputs to subsequent phases.

Low Tolerance
Given that GPUs require all data before starting their job, there is no acceptable tolerance for missing data or out-of-order packets. Packets are sometimes dropped, which causes added latency and higher utilization, and packets may arrive out of order as a result of using per-packet load balancing.

Oversubscription
For non-AI workloads, networks can be configured with a 2:1, 3:1, or 4:1, oversubscription tiers working on the assumption that not all connected devices communicate at maximum bandwidth all the time. For AI workloads, there’s a 1:1 ratio of each leaf’s capacity facing the servers and the spines, as we expect nearly 100% utilization.

Knock-On Effect
Latency, missing packets, or out-of-order packets have a huge knock-on effect on the overall job completion time; stalling one GPU will stall all the subsequent ones. This means that the slowest performing subtask dictates the performance of the whole system.

Networking Features that Support AI Workloads

General-purpose advice for supporting AI workloads includes focusing on end-to-end telemetry, higher port speeds, and the scalability of the system. While these are key components for supporting AI workloads, they are just as important for any type of workload.
To minimize tail latency and ensure network performance, data center switching solutions must support and develop new protocols and optimization mechanisms. Some of these include:

RoCE (RDMA Over Converged Ethernet) and Infiniband

Both technologies use remote direct memory access (RDMA), which provides memory-to-memory transfers without involving the processor, cache, or operating system of either network appliance. RoCE supports the RDMA protocol over Ethernet connections, while Infiniband uses a non-Ethernet based networking stack.

Congestion Management

Ethernet is a lossy protocol, by which packets are dropped when queues overflow. To prevent packets from dropping, data center networks can employ congestion management techniques such as:

Explicit congestion notification (ECN): a technique whereby routers indicate congestion by setting a label in packet headers when thresholds are crossed, rather than just dropping packets to proactively throttle sources before queues overflow and packet loss occurs.
Priority Flow Control (PFC): provides an enhancement to the Ethernet flow control pause command. The Ethernet Pause mechanism stops all traffic on a link, while PFC controls traffic only in one or several priority queues of an interface, rather than on the entire interface. PFC can pause or restart any queue without interrupting traffic in other queues.

Out-of-Order Packet Handling

Re-sequencing of packet buffers properly orders packets that arrive out of sequence before forwarding them to applications.

Load Balancing

We’ll need to compare different flavors of load balancing:

Equal cost multipath (ECMP): Routing uses a hash on flows, sending entire flows down one path, which will load-balance entire flows from the first packet to the last, rather than each individual packet. This can result in collisions and ingestion bottlenecks.
Per-packet ECMP: Per-packet mode hashes each individual packet across all available paths. Packets of the same flow may traverse multiple physical paths, which achieves better link utilization but can reorder packets.
Dynamic or adaptive load balancing: This technique inputs next-hop path quality as a consideration for pathing flows. It can adjust paths based on factors like link load, congestion, link failures, or other dynamic variables. It can change routing or switching decisions based on the current state and conditions of the network.

I recommend this whitepaper from the Ultra Ethernet Consortium as further reading on the topic.

Next Steps

Designing network architectures and features to cater to AI workloads is an emerging technology. While non-specialized networks are still suitable for AI workloads, optimizing the data center switching process will bring considerable returns on investment because more and larger AI deployments inevitably are on the way.

To learn more, take a look at GigaOm’s data center switching Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post The Elephant Flows Through the Data Center Network appeared first on Gigaom.

GigaOm Radar for Cloud Networking

Andrew Green — Mon, 04 Mar 2024 16:00:40 +0000

Cloud networking software enables data transmission within and between clouds by deploying and orchestrating virtual networking functions. Cloud networking is entirely software driven, with each virtual function playing a role in defining how various cloud entities communicate at a logical level, and enables connectivity among different data centers and cloud providers.

Cloud networking solutions use the native networking capabilities from each cloud provider, orchestrating them from a central management solution. Additionally, cloud networking vendors can provide specialized functions such as gateways, exchange points, or routers with more features compared to the native counterparts offered by the cloud providers.

With these capabilities, cloud networking vendors address everyday networking-specific challenges—such as network design, deployment, management, and security—but with a cloud twist. Network segmentation now must span multiple distributed environments, monitoring and observability tools will have larger and more complex networks to understand, optimization should include cloud-to-cloud intelligence, and even routing brings in new networking functions such as transit gateways.

The best way to address these challenges is to abstract all networking constructs and present them in a single orchestration solution that can handle multiple types of infrastructure and provisioning of networking instances with minimal configuration. This consolidated view changes the cloud networking experience from an overwhelming problem to a much more casual activity. Connecting another public cloud environment should feel like just another instance to connect rather than a whole architecture overhaul.

At this higher level of abstraction, service-to-service connectivity and content-aware traffic processing are two of the most important use cases that cloud networking solutions must address. Rather than having the networks team handle constructs at Layers 3 and 4, a cloud networking solution can automatically provision Layer 3 and 4 instances, allowing the DevOps teams to work exclusively at Layer 7 and focus on content-aware, service-to-service connectivity.

With this type of capability at the development teams’ fingertips, applications are no longer bound to a single region or provider, and use cases can expand to multicloud, hybrid cloud, and edge locations. Cloud networking also reduces the amount of vendor-specific knowledge required to interconnect environments by offering a unified and consistent management interface. Rather than adopting an unsophisticated “connecting multiple environments” approach, we can reframe cloud networking as one of the core enablers of developing and maintaining cutting-edge applications using all the available types of infrastructure.

This is our third year evaluating the cloud networking space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Radar report examines 13 of the top cloud networking solutions and compares offerings against the capabilities (table stakes, key features, and emerging features) and nonfunctional requirements (business criteria) outlined in the companion Key Criteria report. Together, these reports provide an overview of the market, identify leading cloud networking offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The post GigaOm Radar for Cloud Networking appeared first on Gigaom.

GigaOm Key Criteria for Evaluating Cloud Networking Solutions

Andrew Green — Mon, 19 Feb 2024 17:23:22 +0000

Cloud networking software enables data transmission within and between clouds by deploying and orchestrating virtual network functions (VNFs). Cloud networking is entirely software driven. Each virtual appliance plays a role in defining how the cloud entities communicate among themselves at a logical level, while also enabling connectivity among different data centers and cloud providers.

The virtualized nature of cloud environments, by which infrastructure is delivered as a service, does not allow cloud tenants the option of deploying hardware appliances as they do at on-premises data centers. Therefore, to enable networking in the cloud, providers have offered the virtual equivalent of appliances such as routers, firewalls, and load balancers. Within a cloud environment’s availability zones, these native tools allow users to logically define their virtual infrastructure estate and create policies that enable applications to communicate with each other without traversing the public internet.

While these cloud-native tools work fairly well within one provider’s environment, communicating across multiple availability zones, public clouds, private clouds, co-location environments, on-premises devices, and edge locations is difficult and hard to secure. Cloud networking providers enhance the capabilities of these native tools with better visibility, multicloud awareness, service insertion, granular controls, enhanced security, and third-party integrations. The cloud networking software we will be evaluating can be deployed in any one environment and can also enable communication among multiple environments.

Whether native or not, cloud networking software is, in essence, the software version of a traditionally physical appliance. It is a collection of VNFs. However, it must offer additional features as well, beyond network function virtualization (NFV), that make it suitable for cloud workloads. Such features include:

Cloud awareness: The solution has visibility and control over the cloud provider’s data centers, regions, or availability zones.
DevOps suitable: To enhance DevOps practices, cloud networking must leverage infrastructure as code (IaC) tools, which can help to include networking as part of the continuous integration and continuous delivery/deployment (CI/CD) methodology.
Application performance: The solution is designed to ensure application performance (and quality of experience) by operating at Layer 7.
Autoscaling: The solution can allocate and retract networking resources dynamically according to demand.

Additionally, modern solutions provide a centralized management platform that offers control over all of the customer’s cloud environments and on-premises data centers. The solution can be interacted with via a graphical user interface (GUI), command-line interface (CLI), or application programming interface (API), or it can be integrated with IaC tools. The management solution can help as well with topological views, troubleshooting, performance monitoring, access controls, and compliance.

Security for cloud networking involves two facets: traffic filtering and secure access. For traffic filtering, we can employ VNFs such as firewalls, either as standalone devices or as part of transit gateways, to create segments and microsegments that isolate applications or databases. For secure access, we use access control lists, zero-trust network access (ZTNA), and multifactor authentication (MFA).

Business Imperative
With the vast majority of enterprises opting for a hybrid and multicloud environment, connectivity across different providers poses a huge operational challenge. Cloud networking solutions enable businesses to connect workloads, services, and applications hosted across different environments with very little configuration. These connections are also automatically updated as environments change, enabling business continuity. Security is also an important use case that is tackled at the network level.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of a cloud networking solution deployment to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a cloud networking solution, we provide an overall Sector Adoption Score (Figure 1) of 4 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that a cloud networking solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for cloud networking are explained in more detail in the Sector Brief section that follows.

Key Criteria for Evaluating Cloud Networking Solutions

Sector Adoption Score

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Figure 1. Sector Adoption Score for Cloud Networking

This is the third year that GigaOm has reported on the cloud networking space in the context of our Key Criteria and Radar reports. This report builds on our previous analysis and considers how the market has evolved over the last year.

This GigaOm Key Criteria report highlights the capabilities (table stakes, key features, and emerging features) and non-functional requirements (business criteria) for selecting an effective cloud networking solution. The companion GigaOm Radar report identifies vendors and products that excel in those decision criteria. Together, these reports provide an overview of the market, identify leading cloud networking offerings, and help decision-makers evaluate these solutions so they can make a more informed investment decision.

GIGAOM KEY CRITERIA AND RADAR REPORTS

The GigaOm Key Criteria report provides a detailed decision framework for IT and executive leadership assessing enterprise technologies. Each report defines relevant functional and non-functional aspects of solutions in a sector. The Key Criteria report informs the GigaOm Radar report, which provides a forward-looking assessment of vendor solutions in the sector.

The post GigaOm Key Criteria for Evaluating Cloud Networking Solutions appeared first on Gigaom.

Andrew Green, Author at Gigaom

GigaOm Radar for Network Observability

GIGAOM KEY CRITERIA AND RADAR REPORTS

GigaOm Key Criteria for Evaluating Full-Stack Edge Deployment Solutions

Key Criteria for Evaluating Full-Stack Edge Deployment Solutions

Sector Adoption Score

DetersAdoption

DiscouragesAdoption

MeritsConsideration

EncouragesAdoption

CompelsAdoption

GIGAOM KEY CRITERIA AND RADAR REPORTS

There’s Nothing Micro About Microsegmentation

Microsegmentation is a Multiple-Entity Construct

Microsegmentation is Not Just Network-Based

Next Steps

GigaOm Key Criteria for Evaluating Network Observability Solutions

Key Criteria for Network Observability Solutions

Sector Adoption Score

DetersAdoption

DiscouragesAdoption

MeritsConsideration

EncouragesAdoption

CompelsAdoption

GIGAOM KEY CRITERIA AND RADAR REPORTS

GigaOm Radar for Microsegmentation

GIGAOM KEY CRITERIA AND RADAR REPORTS

GigaOm Key Criteria for Evaluating Microsegmentation Solutions

Key Criteria for Evaluating Microsegmentation Solutions

Sector Adoption Score

DetersAdoption

DiscouragesAdoption

MeritsConsideration

EncouragesAdoption

CompelsAdoption

GIGAOM KEY CRITERIA AND RADAR REPORTS

The Cloud Networking Polysemy

Different Approaches to Cloud Networking

Which is the Best Approach?

Next Steps

The Elephant Flows Through the Data Center Network

AI Traffic Patterns in Data Center Networks

The Basics

More Complex Processes

Networking Features that Support AI Workloads

RoCE (RDMA Over Converged Ethernet) and Infiniband

Congestion Management

Out-of-Order Packet Handling

Load Balancing

Next Steps

GigaOm Radar for Cloud Networking

GIGAOM KEY CRITERIA AND RADAR REPORTS

GigaOm Key Criteria for Evaluating Cloud Networking Solutions

Key Criteria for Evaluating Cloud Networking Solutions

Sector Adoption Score

DetersAdoption

DiscouragesAdoption

MeritsConsideration

EncouragesAdoption

CompelsAdoption

GIGAOM KEY CRITERIA AND RADAR REPORTS

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption