Ixia takes aim at cloud visibility with its new CloudLens Public for tracking cloud performance.
Nearly everyone has experienced the situation where, while driving down the road, the car’s check-engine light suddenly illuminates. It’s a helpless feeling. There is no way to tell if it’s a simple problem or a big one. Nor do you know whether it will take a long time to fix, or if there’s an easy solution.
I’m sure IT people feel the same way about cloud performance problems. In their case, the “check cloud” light comes on when users start calling with problems. My research shows 75% of application performance problems are discovered by the end user, and not the IT department. This means IT is always working in firefighting mode.
While the scenario with the car isn’t a perfect analogy — as it’s easy to rent a car for a few days while yours is in the shop, and it’s not like CIOs can use a second cloud that’s in their garages — the overall message is the same.
IT needs ability to diagnose problems quickly
Given the importance of the cloud, it’s critical that businesses have the necessary cloud visibility tools to see into their providers’ data centers and be able to diagnose problems quickly. The network is the fabric that connects the cloud to the business, but network engineers typically are blind to anything off the business network.
This week, Ixia, based in Calabasas, Calif., introduced some updates to its CloudLens software that extend the product into public clouds for increased cloud visibility. CloudLens Public is now available for Amazon Web Services, and it will be extended for use within Microsoft Azure and Google Cloud environments during the last half of 2017.
Customers can run CloudLens Public for free for up to 45 days. After that, Ixia uses a consumption-based pricing model based on both the number of hours CloudLens Public is in operation and the amount of data transferred. The more sensors and more data that is transmitted, the lower the pricing tiers.
There are a few other vendors that have products that claim to provide cloud visibility, but Ixia’s is the first to support a cloud-native visibility infrastructure.
In the software-as-a-service (SaaS) world, there are two ways to migrate an application or service to the cloud. The first is to “lift and shift” the workload into the cloud. This is the fastest route to market, but it doesn’t take advantage of the scalability, agility and elasticity of the cloud. The more difficult approach is to start from scratch and build a cloud-native service. This is a superior strategy in the long run, as the resulting service is specifically built for the cloud, giving it long-term sustainability.
Ixia took the long view, built CloudLens Public for the cloud and now offers what it calls “visibility as a service” (VaaS) that is built on the following two components:
- Docker-based sensors that run within a customer’s source and tool instances in the public cloud. Because they run in the environment, they inherit the security configuration of those instances. The sensors have access to the data stored in the cloud, and the platform can be programmed to monitor new instances and automatically adjust for proper monitoring. The fact that these Docker sensors sit behind a customer’s security structure is significant for maintaining security structure, privacy and compliance. Finally, Docker-based architecture makes CloudLens Public provider-agnostic and easy to port to any cloud service that may emerge in the foreseeable future.
- A SaaS-based interface where the cloud visibility is managed. By making this available as a cloud service, there is no requirement to backhaul all the data to the customer’s premises, saving massive amounts of bandwidth. Also, setup is a breeze, as there’s nothing on premises to deploy and configure. The other advantage of CloudLens’ SaaS foundation is network engineers have access to it from anywhere.
Visibility spins up and down as needed
The most obvious benefit of the VaaS offering is elastic scalability. Businesses use the cloud to spin up and down resources as necessary. Now, the visibility infrastructure can also spin up or down as needed. With a lift-and-shift approach, increasing or reducing capacity could require manual intervention. Also, because the packets are filtered at each source instance, the inline virtual packet broker is no longer a single point of failure like it can be with the lift-and-shift design.
PRO+
Content
Find more PRO+ content and other member only offers, here.
E-Handbook
Modern management of a virtualized network: Tips and techniques
What’s more, since the cloud visibility is embedded within the instance structure, network engineers do not need to be concerned with cross-tenant violations, which can lead to security breaches. Lastly, because the visibility is initiated from behind the Secure Sockets Layer offload services, there is no need to have a separate set of tools for decryption. This alone can save a significant amount of money and compute resources.
I’ve never been a big fan of the lift-and-shift strategy of migrating anything to the cloud. I understand there are some short-term benefits, but it can cause some long-term pain, as the workload will eventually need to become cloud-native. It was certainly in users’ best interest that Ixia not rush another “me too” product for cloud visibility, but rather build a product that enables network engineers to monitor their cloud operation — both today and into the future as demands change.