Cloud-Native Visibility – Visibility as a Service (VaaS)
With enterprises migrating more of their critical applications to cloud services, traditional visibility architectures no longer offer the agility and insight required to ensure proper operation and security of cloud workloads. As 451 Research states, “the concurrent movement to the cloud is obscuring visibility, which impacts IT security and compliance.” Ixia addresses this transition with a true cloud-native visibility solution offered via a SaaS architecture and consumption model – Visibility-as-a-Service, or VaaS.
As a review, on-premises visibility has evolved over the last decade with increasingly effective tools, able to keep up with changes in enterprise, data center, and carrier network architectures and services. The sophistication of the different security, monitoring, and performance tools that connect to the visibility architecture has also kept pace. On-premises solutions depend on physical hardware, taps, and an assumption that the deployment doesn’t suddenly grow or shrink by an order of magnitude overnight. Virtualization and even on-premises container deployments add a wrinkle to this, but the physical server architecture doesn’t fundamentally change and the network remains as-is. The introduction of SDN impacts software and control but only requires changes as to how the visibility architecture relates to the network.
But this all changes with the move to the public cloud. The physical servers and network infrastructure are now under the control of a cloud service provider such as AWS, Google Cloud Platform, or Microsoft Azure. However, the enterprise, as part of an IaaS deployment on its selected cloud service provider, still requires visibility into server workloads. Here, there are two approaches.
The first is to adapt the current on-premises architecture, adding agents in the cloud that deliver the visibility traffic to a ‘virtual’ visibility node, then forwarding the traffic to a conventional physical visibility node. Although this meets many of the basic visibility requirements of cloud-based workloads, it doesn’t really embrace the cloud, and is incapable of making direct use of the rich set of cloud-native applications offered by the cloud service providers. Because of this, it doesn’t reflect true cloud elasticity, and more importantly, it does not permit enterprises to consume visibility-as-a-service (irrespective of vendor marketing) since it is implemented as an IaaS architecture. A true cloud-native visibility architecture looks very different.
Instead of starting with a physical paradigm and then adapting it to the cloud, we need to take the opposite approach, starting with the cloud and leveraging cloud-native services. Here, the first step is creating an orchestration layer, accessible via a SaaS-based web interface that leverages native cloud service provider databases, identity management, APIs, and other services. This is the intelligence at the core of VaaS, with the enterprise no longer required to install or manage any part of the offering.
As an analogy, consider cloud-based file storage services. You are only interested in your content, and not the mechanics of how and where your files are stored. The service would be much less appealing if you had to provision and manage disk drives, even virtual, decide where these drives reside, and then manually manage sharing. Your selected cloud storage provider’s orchestration layer does all of this for you.
In a VaaS model, the orchestration layer connects to sensors and to the various security and monitoring tools. The most efficient and scalable way to deploy these sensors is via containers, embedded in the same instances as the customer’s micro-service based workloads. Since they are embedded directly in the instances, they are capable of filtering for relevant visibility traffic at the source. The orchestration layer also connects to monitoring and security tools, and the architecture must then support secure communication between the sensors and the tools. Ideally, the tools will also support container-based deployments, and scale in the same way as the sensors, but this is not a requirement. Beyond simple efficiency, there is another fundamental advantage of embedding the sensors in the source instances.
This is the concept of metadata, where the sensors know the type of workload, such as database or web, and communicate this to the orchestration layer. Since tools are associated with different workload types, the enterprise may then create ‘groups’ that bind the sensors and the relevant tools. As additional instances of a given service are spun-up, these immediately cause the creation of additional sensors, which then connect to the relevant tools. As additional sensors are brought on-line within a group, the tools are also scaled automatically since they too reside within the container environment. This is true cloud-native elasticity, with no manual intervention.
The ability to scale on-demand, both the sensors and the tools, and to leverage cloud-native services, is core to visibility-as-a-service. The architecture for the first time enables a SaaS, OpEx-based consumption model that aligns to the other SaaS services that enterprise uses. And, it is extensible to support any of the major cloud service providers, providing the enterprise with the required visibility as part of a multi-cloud deployment.