Go Cloud-Native, For if the Flies!
Unless you speak fluent, native-proficiency Spanish, that phrase may seem like I had a copy-paste error. However, the phrase por si las moscas—literally “for if the flies”—is the Spanish equivalent of the phase “just in case.”
This demonstrates the caveat of thinking in one language and then translating it to another—it is an intrinsically flawed process where context, emotion, and even rhythm are usually lost.
Technologies are like languages (puns about coding aside). Think about cloud applications—why do cloud-native products gain traction in mature markets and leave incumbents working to “pivot” and catch up? It is because the cloud-native is the fluent speaker who learns the language to understand what the world even is: no baggage. The incumbent is equivalent to an adult who moves overseas at middle age, newly divorced or separated from the old tech and working to learn as quickly as possible to avoid becoming obsolete: tons of baggage.
I know, why does everyone and their mother use cloud as the example? (How well would that translate?)
It is because the cloud is a paradigm shift—a new language, not just slang. So, how can we think like a native speaker when it comes to cloud visibility? We must start by acknowledging that the physical constructs that made taps, bypasses, and network packet brokers great solutions do not fit the cloud. Moreover, the solutions we do come up with must maintain the integrity of what makes cloud great—flexibility, elasticity, and scale.
Now, we may wonder how could we tell the difference between a cloud-native and say someone who is good at learning languages and is incredibly proficient. The cloud-native computing foundation (CNCF) says cloud-native computing uses an open software stack and demonstrates the following characteristics:
“Containerized. Each part (applications, processes, etc.) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.
Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization.
Microservices oriented. Applications are segmented into microservices. This significantly increases the overall agility and maintainability of applications.”
Other characteristics include self-provisioning, pay-per-use billing (consumption model), and linear scalability.
Keeping these characteristics and the requirements of a visibility solution in mind, Ixia has developed a cloud visibility solution that is a software-as-a-service (SaaS) built on the cloud itself. CloudLens™ Public, the public cloud arm of Ixia’s CloudLens platform, achieves these characteristics.
CloudLens Public has two core components:
- A SaaS visibility management platform. This is where users can configure visibility and define filtering.
- Sensors and connectors that are containerized, Docker-based software that sit within the source and tool instances. The sensors access and filter data to send to security, monitoring, and analytics tools.
Now, turning to the characteristics that would make CloudLens “cloud-native”:
CloudLens is containerized – it uses Docker-based, containerized elements (sensors and connectors) to access and receive packet data. These containers are dynamically orchestrated—actively scheduled and managed by the platform to optimize resource use as instances that are being monitored scale-out and in based on demand; this achieves linear scale.
CloudLens is microservices oriented. It uses a serverless architecture that leverages several AWS products: Amazon DynamoDB for its database, AWS Lambda to run its code, and even AWS IAM for its management layer.
CloudLens is easily purchased online, where users self-provision and can get started right away, and it is billed in a pay-per-use model much like other cloud products.
Instead of cloud-native, Ixia could have opted to do a translation from the physical world to the virtual—what some in the industry would call a “lift and shift”—something along the lines of creating a virtual machine (VM) appliance that does the functions of physical packet broker. It would use virtual taps instead of physical and terminate to the VM for filtering, etc. Though this approach may have allowed a faster-to-market solution, much is lost in translation: flexibility, elasticity, and scale.
Such a translation from the physical to cloud space has limitations:
- It creates a single point of failure that limits maximum achievable performance
- It requires humans to maintain and update static configurations, basically creating a whole construct to manage that complicates the end users’ ability to achieve elastic scale
- It requires sizing to the peak demand for the visibility solution. This violates a core tenet of cloud adoption: only paying for what you need and never having to guess what that will be
However, by being cloud-native, Ixia’s CloudLens does not have any of those issues and provides all the benefits of the cloud:
- Elasticity – so visibility autonomously scales horizontally along with the instances being monitored and the instances that perform the monitoring
- Automation and visibility-as-a-service (VaaS) – so there is nothing to manage
- Cost effectiveness – because the solution also scales in when demand goes down; customers only use and pay for what they need
Moreover, CloudLens is cloud service provider agnostic because it leverages a Docker-based container approach. A Docker container can be used on any cloud platform.
If you were traveling and had the option of a good translator for a second language vs. someone who was a native, fluent speaker of both languages, who would you choose? Wouldn’t you go native, pos si las moscas?