Arista CloudVision is one of the most operationally powerful platforms in enterprise networking. Organizations that deploy it correctly, with deliberate configlet design, compliance rules, streaming telemetry, and zero-touch provisioning, manage significantly larger device counts with the same or smaller teams compared to equivalent Cisco environments managed through CLI.
Most CloudVision deployments don't reach that state. Devices get enrolled. The dashboard comes up. Telemetry streams in. And then the operational model reverts: engineers log into devices individually through the familiar CLI interface, make changes directly on the device, and use CloudVision as a read-only visibility tool rather than the management plane it's designed to be. The platform is being paid for. The value isn't being extracted from it.
Configlets are CloudVision's configuration management mechanism: template-based configuration blocks that define the intended state for each device or device role and can be pushed, audited, and compliance-checked at fleet scale. They are the mechanism through which CloudVision becomes a management plane rather than a dashboard.
The most common configlet failure mode is configlets that are too granular, too specific, or poorly structured for reuse. An organization with 200 access switches has written 200 individual device configlets (one per device) rather than a set of role-based configlets (access-switch-standard, distribution-switch-standard, core-switch-standard) with device-specific variable overrides. The result is that "managing through configlets" requires more work than managing through CLI, so engineers don't use the configlets, and the management model falls back to per-device CLI.
Correctly designed configlets express the standard configuration for a device role, not the specific configuration of a specific device. They use CloudVision's template variable system to handle device-specific values without creating device-specific configlet clones, cover the complete standard configuration for each role, and are versioned and documented so the team knows what each configlet controls and why.
CloudVision's compliance feature compares current device configuration against the configlet-defined baseline and surfaces any drift. It's the mechanism that makes configuration management continuous rather than periodic — and it requires compliance rules to be configured against your baseline.
The failure mode: CloudVision is deployed, configlets are built, and compliance rules are never configured. The compliance dashboard shows nothing because there's nothing to compare against. Configuration drift accumulates invisibly.
Configuring compliance rules requires defining what "compliant" looks like for each device role, specifically, which configlet content is mandatory and which represents the compliance baseline. Once compliance rules are in place, CloudVision surfaces drift in real time - the moment a device configuration deviates from baseline, the compliance view shows the specific diff. For organizations with PCI DSS, SOX, or other compliance obligations that touch network configuration, this continuous compliance visibility produces the audit evidence that manual configuration review cannot.
CloudVision collects streaming telemetry from enrolled EOS devices at sub-second intervals: interface counters, BGP session state, MLAG bond health, system resources, buffer utilization, and dozens of other metrics that represent real-time device state. This is one of Arista's most significant operational advantages over SNMP-polled environments.
The failure mode: telemetry is streaming, the data is in CloudVision, and nobody has configured dashboards or alerts to surface operational insights from it. The data is there but invisible because the analytical layer hasn't been built.
CloudVision's telemetry data requires configuration to be operationally useful: dashboards that surface the metrics your team actually acts on, alert thresholds configured against observed baselines, and historical trend views that enable root cause analysis. The automation and CloudVision practice at IVI includes dashboard and alert configuration as a deliverable, because telemetry without instrumentation for operational use is a data archive, not an operational tool.
ZTP is one of CloudVision's highest-value operational capabilities: new Arista devices boot, connect to the network, register with CloudVision, and receive their full configuration automatically without requiring manual CLI access. In environments with regular device replacement, expansion, or new site deployments, ZTP eliminates the per-device configuration work that is one of the highest time consumers in network operations.
The failure mode: ZTP was never configured because it requires upfront work to set up the provisioning server, the boot configuration, and the DHCP options that direct new devices to CloudVision. Organizations that didn't invest in ZTP at initial deployment continue manually configuring each new device, and the opportunity cost compounds with every subsequent deployment.
ZTP implementation requires configuring the CloudVision ZTP server, defining the device role identification logic, and testing the end-to-end workflow against a physical device before relying on it in production. The return on investment is immediate for environments with regular device additions or replacements.
The highest-value operational change from full CloudVision operationalization is running the change management process through the platform, designing changes as configlet modifications, deploying them through CloudVision's change control workflow, and using the platform's audit log as the change management record.
The failure mode: changes are still being made through direct device CLI access because that's the familiar workflow, and CloudVision is used after the fact to verify what was changed. This produces a change management process that is CloudVision-adjacent rather than CloudVision-driven, losing most of the compliance and operational discipline benefits.
Running changes through CloudVision requires a documented workflow for how changes are proposed, reviewed, and deployed, configlets that are updated when the standard changes, and team discipline to treat direct device CLI access as an exception path rather than the default operational path. Our co-managed operations engagements for Arista environments include explicit CloudVision workflow training and the documentation of CloudVision-driven change management processes for exactly this reason.
An Arista environment operating CloudVision at full capability has all five gaps addressed: a role-based configlet library with template variables for device-specific configuration, compliance rules that continuously surface configuration drift against the baseline, telemetry dashboards and alert configurations calibrated for your environment, ZTP provisioning flow for new and replacement devices, and a change management workflow that runs through CloudVision's audit trail.
The operational result: a team managing a large campus network with the same or smaller headcount than before, with better compliance evidence, faster incident diagnosis, and less time spent on per-device configuration work. The productivity numbers in environments we've taken from poorly operationalized to fully operationalized CloudVision can be significant and are typically measured in engineering hours per week recovered and change risk events reduced.