Andrew Green, Author at Gigaom

GigaOm Radar for Edge Development Platforms

Andrew Green — Tue, 25 Jun 2024 15:00:06 +0000

Edge development platforms operate globally distributed infrastructure and offer computing and developer services for creating and running applications closer to end users. These solutions are built upon geographically distributed points of presence (PoPs) that are connected by a global network backbone. These PoPs behave as mini data centers situated within 20 milliseconds of major metropolitan areas, thereby considerably reducing the network latency associated with running workloads off-device.

While reducing network latency is a core feature of edge-related solutions, organizations also need to consider and tackle challenges associated with compute latency, or the time it takes to spin up and process a request. To do this, edge development platforms are exploring edge-native execution environments, which are runtimes optimized for quickly processing web requests. These execution environments typically run directly on bare metal without requiring data center-grade hypervisors or operating systems.

Lastly, these solutions also reduce storage-related latency by using key-value stores. These offer very fast performance for reads and writes because the database is looking for a single key and returns its associated value rather than performing complex aggregations.

By reducing network, compute, and storage latency, edge development platforms simultaneously deliver the speed of running workloads locally and the centralized and modular capabilities of the cloud.

This report is a new iteration of our initial definition, with more focus on compute capabilities and developer experience. To capture this change, we have renamed the report “edge development platforms,” where previously it was just “edge platforms.” This new name also reflects some considerable changes in the vendor landscape, where multiple players have sold their content delivery network (CDN) businesses to focus exclusively on edge compute.

This is our fourth year evaluating the edge development platforms 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 edge development platforms 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 edge development platform 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 Edge Development Platforms appeared first on Gigaom.

GigaOm Key Criteria for Evaluating Edge Development Platforms

Andrew Green — Mon, 17 Jun 2024 13:39:45 +0000

Edge development platforms operate globally distributed infrastructure and offer computing and developer services for creating and running applications closer to end users. They are built upon novel technology stacks that are optimized for near-instant processing of web requests, minimizing the latency associated with networking, compute, and storage. They do this by operating globally distributed points of presence (PoPs) located close to end users, running edge-native execution environments, and employing simple and fast storage architectures.

Edge development platforms are an evolution of content delivery networks (CDNs), which, though still relevant, have remained architecturally stagnant since the early 2000s. CDNs rely on global PoPs to cache web resources for quicker load times.

By far the most important asset of CDNs is their geographically distributed infrastructure. Upon this foundation, other providers of global infrastructure, such as cloud and telecommunications providers, have built content delivery applications, contributing to the evolution of the CDN market.

Edge computing brought a considerable shift in the market, which manifests itself in the following ways:

CDNs employ edge compute for advanced web delivery use cases, such as real-time web page personalization.
Multiple vendors have sold their CDN businesses to focus exclusively on edge compute services.
Newer vendors are building edge development platforms from scratch, bypassing content delivery applications.

This iteration of the report attempts to capture the evolution of this space. Previously named Edge Platforms and focused on content delivery features and edge compute capabilities, this report has been updated as Edge Development Platforms, which now evaluates compute services and the developer experience rather than content delivery.

Most use cases addressed by these solutions involve services that are accessed by consumers through websites, typically in industries such as ecommerce, digital media, financial services, healthcare, and others. However, we expect an increase in some enterprise use cases, especially involving IoT, OT, or other field-related applications, far away from office locations.

Business Imperative
Considering that most use cases for edge development platforms are related to web-based resources, organizations will have already developed some delivery and optimization mechanisms. This means that deploying or migrating to an edge development platform will likely pose only incremental product evolutions. For example, an ecommerce organization will have most of the core functionality in place but could use an edge development platform to roll out features such as real-time offers or session-sensitive personalized product recommendations.

There may be some novel use cases that fully depend on low latency that can’t be achieved on cloud infrastructure, in which case the need to deploy an edge development platform will be considerably higher.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of an edge development platform 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 an edge development platform, 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 an edge development platform is a credible candidate for deployment and worthy of thoughtful consideration.

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

Key Criteria for Evaluating Edge Development Platforms

Sector Adoption Score

Deters
Adoption

Discourages
Adoption

Merits
Consideration

Encourages
Adoption

Compels
Adoption

Figure 1. Sector Adoption Score for Edge Development Platforms

This is the fourth year that GigaOm has reported on the edge development 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 edge development platform. 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 edge development platforms, 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 Edge Development Platforms appeared first on Gigaom.

Near, Far, Wherever Your CPUs Are

Andrew Green — Tue, 04 Jun 2024 13:43:20 +0000

Over the past two years, I’ve been making the point that near edge and far edge are utilitarian terms at best, but they fail to capture some really important architectural and delivery mechanisms for edge solutions. Some of those include as-a-service consumption versus purchasing hardware, global networks versus local deployments, or suitability for digital services versus suitability for industrial use cases. This distinction came into play as I began work on a new report with a focus on specific edge solutions.

The first edge report I wrote was on edge platforms (now edge dev platforms), which was essentially a take on content delivery networks (CDN) plus edge compute, or a far-edge solution. Within that space, there was a lot of attention on where the edge is, which is irrelevant from a buying perspective. I won’t base a selection on whether a solution is a service provider edge or a cloud edge as long as it meets my requirements—which may involve latency but are more likely to be ones I mentioned in the opening paragraph.

Near Edge Vs. Far Edge

I talked about this CDN perspective in an episode of Utilizing Edge. The conversation— co-hosted by former GigaOm analyst, Alastair Cooke—went into the far-edge and near-edge conundrum. Alastair, who wrote the GigaOm Radar for Hyperconverged Infrastructure (HCI): Edge Deployments report (which I didn’t realize until a year later), brought experience from the near-edge perspective, just as I came in with the far-edge background.

One of my takeaways from this conversation is that the difference between CDN-based edges (far edge) and HCI deployments (near edge) is pushing versus pulling. I’m glad I only realized Alastair wrote the Edge HCI report after the fact because I had to work through this push versus pull thing myself. It’s quite obvious in retrospect, mainly because a CDN delivers content, so it’s always been about web resources centrally hosted somewhere that get pushed to the users’ locations. On the other hand, an edge solution deployed on location has the data generated at the edge, which you can then pull to a central location if necessary.

So, I made the case to also write a report on the near edge, where we evaluate solutions that are deployed on customers’ preferred locations for local processing and can call back to the cloud when necessary.

Why the Edge?

You may ask yourself, what’s the difference between deploying this type of solution at the edge and just deploying traditional servers? Well, if your organization has edge use cases, you likely have a lot of locations to manage, so a traditional server architecture can only scale linearly, which includes time and effort.

An edge solution would need to make this worthwhile, which means it must be:

Converged: I want to deploy a single appliance, not a server, a switch, external storage, and a firewall.
Hyperconverged: As per the above, but with software-defined resources, namely through virtualization and/or containerization.
Centrally managed: A single management plane to control all these geographically distributed deployments and all their resources.
Plug-and-play: The solution will provide everything needed to run applications. For example, I do not want to bring my own operating system and manage it if I don’t have to.

In other words, these must be full-stack solutions deployed at the edge. And because I like my titles to be representative, I’ve called this evaluation “full-stack edge deployment.”

Defining Full-Stack Edge

All the bullet points above became the table stakes—features that all solutions in the sector support and therefore do not materially impact comparative assessment. Table stakes define the minimum acceptable functionality for solutions under consideration in GigaOm’s Radar reports. The most considerable change between the initial scoping phase and the finished report is the hardware requirement. I first defined the report by looking at integrated hardware-software solutions, such as Azure Stack Edge, AWS Outposts, and Google Cloud Edge. I have since dropped the hardware requirement as long as the solution can run on converged hardware. This is for two reasons:

The first reason is that evaluating hardware as part of the report would take away from all the other value-adding features I was looking to evaluate.
The second reason is that we had a lot of engagement from software-only vendors for this report, which is a rear-view way of gauging that there is demand in this market for just the software component. These software-only vendors typically have partnerships with bare metal hardware providers, so there is little to no friction for a customer to procure both at the same time.

The final output of this year-long scoping exercise—the full-stack edge deployment Key Criteria and Radar Reports—defines the features and architectural concepts that are relevant when deploying an edge solution on your preferred location.

Simply saying “near edge” will never capture nuances such as an integrated hardware-software solution running a host OS with a type 2 hypervisor where virtual resources can be defined across clusters and third-party edge-native applications can be provisioned through a marketplace. But full-stack edge deployments will.

Next Steps

To learn more, take a look at GigaOm’s full-stack edge deployment 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, sign up here.

The post Near, Far, Wherever Your CPUs Are appeared first on Gigaom.

Could Network Modeling Replace Observability?

Andrew Green — Tue, 04 Jun 2024 13:39:22 +0000

Over the past four years, I’ve consolidated a representative list of network observability vendors, but have not yet considered any modeling-based solutions. That changed when Forward Networks and NetBrain requested inclusion in the network observability report.

These two vendors have built their products on top of a network modeling technology, and both of them met the report’s table stakes, which meant they qualified for inclusion. In this iteration of the report, the fourth, including these two modeling-based vendors did not have a huge impact. Vendors have shifted around on the Radar chart, but generally speaking, the report is consistent with the third iteration.

However, these modeling solutions are a fresh take on observability, which is a category that has so far been evolving incrementally. While there have been occasional leaps forward, driven by the likes of ML and eBPF, there hasn’t been an overhaul of the whole solution.

I cannot foresee any future version of network observability that does not include some degree of modeling, so I’ve been thinking about the evolution of these technologies, the current vendor landscape, and whether modeling-based products will overtake non-modeling-based observability products.

Even though it’s still early days for modeling-based observability, I want to explore and validate these two ideas:

It’s harder for observability-only tools to pivot into modeling than the other way around.
Modeling products offer some distinct advantages.

Pivoting to Modeling

The roots of modeling solutions are based in observability—specifically, collecting information about the configuration and state of the network. With this information, these solutions create a digital twin, which can simulate traffic to understand how the network currently behaves or would behave in hypothetical conditions.

Observability tools do not need to simulate traffic to do their job. They can report on near-real time network performance information to provide network operations center (NOC) analysts with the right information to maintain the level of performance. Observability tools can definitely incorporate modeling features (and some solutions already do), but the point here is that they don’t have to.

My understanding of today’s network modeling tools indicates that these solutions cannot yet deliver the same set of features as network observability tools. This is rather expected, as a large percentage of network observability tools have more than three decades of continuous development.

However, when looking at future developments, we need to consider that network modeling tools use proprietary algorithms, which have been developed over a number of years and require a highly specific set of skills. I do not expect that developers and engineers equipped with network modeling skills are readily available in the job market, and these use cases are not as trendy as other topics. For example, AI developers are also in demand, but there’s also going to be a continuous increase in supply over the next few years as younger generations choose to specialize in this subject.

In contrast, modeling tools can tap into existing observability knowledge and mimic a very mature set of products to implement comparable features.

Modeling Advantages

In the vendor questionnaires, I’ve been asking these two questions for a few years:

Can the tool correlate changes in network performance with configuration changes?
Can the tool learn from the administrator’s decisions and remediation actions to autonomously solve similar incidents or propose resolutions?

The majority of network observability vendors don’t focus on these sorts of features. But the modeling solutions do, and they do so very well.

This list is by no means exhaustive; I’m only highlighting it because I’ve been asking myself whether these sorts of features are out of scope for network observability tools. But this is the first time since I started researching this space that the responses to these questions went from “we sort of do that” to “yes, this is our core strength.”

This leads me to think there is an extensive set of features that can benefit NOC analysts that can be developed on top of the underlying technology, which may very well be network modeling.

Next Steps

Whether modeling tools can displace today’s observability tools is something that remains to be determined. I expect that the answer to this question will lie with the organizations whose business model heavily relies on network performance. If such an organization deploys both an observability and modeling tool, and increasingly favors modeling for observability tasks to the point where they decommission the observability tool, we’ll have a much clearer indication of the direction of the market.

To learn more, take a look at GigaOm’s network observability 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, sign up here.

The post Could Network Modeling Replace Observability? appeared first on Gigaom.

GigaOm Radar for Full-Stack Edge Deployment

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

Full-stack edge deployment solutions are cloud-managed and cloud-connected hyperconverged tools that provide all the capabilities necessary to run applications at customers’ preferred locations for local data collection and processing.

These solutions bring a cloud-like experience to edge locations, which are otherwise difficult to manage at scale with traditional IT practices, especially in a DevOps-oriented and agile organization. These solutions are labeled as full-stack because they offer customers all the required technologies at all levels to manage their edge deployments. For example, customers do not need to provide or manage operating systems (OSs).

This means that the solutions can run on bare metal hardware, providing type 1 hypervisors, or OSs with type 2 hypervisors and/or containerization engines. The solutions can then deploy and run applications, often by self-service mechanisms consumed from a service catalog. Advanced solutions can enable customers to build their applications natively on the platform, which can take advantage of edge-native runtimes. Further, administrators can interact programmatically with the solution and provide a suite of visibility and troubleshooting tools.

These solutions are also labeled as “edge deployments” to differentiate them from as-a-service edge solutions, such as those provided by content delivery networks (CDNs) or edge development platforms. In other words, full-stack edge deployments are “near edge” solutions.

Particularly important use cases are those for which applications need:

To run in air-gapped environments with limited or unstable network connectivity.

To support latency-sensitive use cases for near-real-time processing.

To enable data to remain local due to legislative or regulatory requirements.

To act as an alternative where data transfers from the edge are prohibitive from either a performance or cost point of view.

To simplify cloud architectures, especially in geographically distributed scenarios.

To remove dependencies on cloud platforms because customers have no control over the underlying infrastructure and virtualization technologies.

To optimize costs, such as through storage cost savings using storage tiering and minimizing data transfer costs.

The solutions that qualify to be in this report all deliver full-stack edge deployments but come from different backgrounds and can tackle specific use cases. We capture the differences in their ability to scale, which must be delineated in terms of support for scaling-up, scaling-out, and scaling-down.

Those that scale up can support large workloads and massive amounts of data to be stored and processed on their nodes; those that scale out can manage thousands of geographically distributed nodes; and those that scale down offer lightweight virtualization and runtimes that consume very small amounts of compute and memory resources, suitable for internet of things (IoT) deployments and small form-factor devices. It’s important to note that a vendor can deliver on more than one of these scalability types.

This is our first year evaluating the full-stack edge deployment space in the context of our Key Criteria and Radar reports. This GigaOm Radar report examines 16 of the top full-stack edge deployment 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 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 Radar for Full-Stack Edge Deployment appeared first on 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 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.

Andrew Green, Author at Gigaom

GigaOm Radar for Edge Development Platforms

GIGAOM KEY CRITERIA AND RADAR REPORTS

GigaOm Key Criteria for Evaluating Edge Development Platforms

Key Criteria for Evaluating Edge Development Platforms

Sector Adoption Score

DetersAdoption

DiscouragesAdoption

MeritsConsideration

EncouragesAdoption

CompelsAdoption

GIGAOM KEY CRITERIA AND RADAR REPORTS

Near, Far, Wherever Your CPUs Are

Near Edge Vs. Far Edge

Why the Edge?

Defining Full-Stack Edge

Next Steps

Could Network Modeling Replace Observability?

Pivoting to Modeling

Modeling Advantages

Next Steps

GigaOm Radar for Full-Stack Edge Deployment

GIGAOM KEY CRITERIA AND RADAR REPORTS

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

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