Isovalent Reviews

My main use case for Isovalent is to show partners how to secure the infrastructure on which AI runs, specifically cloud-native applications. Isovalent excels at securing and observing cloud-native applications due to eBPF usage.

I have helped major partners including WWT, SHI, and NTT understand how these systems work. Taking my application that I have developed, a cloud-native application with AI embedded in it, we would put it under a CNI such as a normal CNI and then we would use Cilium CNI and all of its service mesh and cluster mesh, and they would see the efficiency and observability, primarily observing the actual pods without sidecars. This is a wonderful example of how efficient and secure Isovalent is. Additionally, Tetragon showcases its ability to secure the application from the kernel side.

I explain to partners that Isovalent is the secure highway on which all of the applications that drive AI or any other commerce will be in the future.

The accuracy and reliability of Isovalent's output are perfectly acceptable. I have not observed much hallucination from it at all.

We have shown partners how to observe an application and then how to measure with an application performance monitor (APM) the differences between the demo system we run in Isovalent and the same system with the same pods running on Flannel. They are seeing somewhere around a 30% efficiency gain or loss of latency.

In reducing overall latency to the numbers I mentioned before, this has increased usability without spending more money, so a return on investment is instantaneous. In the long run, not having to staff specific AWS, GCP, and Azure engineers will also result in cost savings.

I think they need to continue developing their load balancing and possibly even a more efficient DNS system.

User interfaces are dependent on each customer, whether they're going to use something like Grafana or, in our case at Cisco, we will be using Splunk. The observability parts within Timescape are fine, and I am sure they will improve over time.

Governance and security depend on the approach each customer will take to deploying the systems. You can do the minimums or really dive into observability and governance over any of the ecosystems. This is an individual journey, and Isovalent makes it easier. Before Isovalent, we struggled with just simple pod observability with products like Kalisti that sat on the side of the sidecar. Adding all these products added latency, so we tuned the environment as quickly as possible to be as efficient as possible, especially if you're using cloud resources.

I have been using Isovalent for three years since our company acquired them.

Isovalent is very stable.

Isovalent's scalability is excellent.

The customer support is first rate. I would rate the customer support a nine.

I have used just about all of them, from Istio to Kuma, Kong, and more.

In reducing overall latency to the numbers I mentioned before, this has increased usability without spending more money, so a return on investment is instantaneous. In the long run, not having to staff specific AWS, GCP, and Azure engineers will also result in cost savings.

There is no other eBPF-based CNI.

If you have any second thoughts, I would run the open-source version in your test environment and run it against your current systems to observe the efficiencies you gain. I would rate this product a nine overall.

I have been using Isovalent for a very short duration; last year, mostly about 10 months ago, I was given a task to create a product called Tezz, which is an observability platform utilizing certain Kubernetes microservices, and to meet the standard of security, I explored tools for Kubernetes microservices hardening, leading me to Isovalent, where I took courses to understand it better. Isovalent, especially the Cilium tool, is very good as it provides capabilities to harden microservices not just based on Layer 3 and Layer 4.

In today's landscape, where security is crucial, we need to restrict communication between pods within a cluster, as this design is typically challenging due to the ephemeral nature of pod IPs and ports, and Cilium addresses this by allowing tagging, which permits easier restrictions based on front-end and back-end pod interactions.

While I am not currently using Isovalent, we have used it in our past project mainly to harden the microservices, specifically referencing our TICK stack, which comprises Telegraf, InfluxDB, and Grafana, where I was the End-to-end Architect tasked with securing the microservices. In this project, I evaluated various tools for hardening, and Isovalent emerged as essential with Cilium, which is a CNI for Kubernetes, allowing us to write YAML policies injecting into Helm charts for the TICK stack, enabling restricted communication between the pods in the cluster while hardening the entire product.

When writing those policies and restricting communications between the pods, we faced challenges as the team was unfamiliar with the new tool and initially used different CNIs, with the major challenge being how to implement this CNI and redeploy our entire cluster, including restarting the pods. Our use case focused primarily on hardening the internal pods, which did not necessitate complex routing restrictions, and we designed tagging for different cluster components such as back-end pods, front-end pods, middleware, and two Kafka instances, successfully restricting communication among these internal clusters.

Though my experience with Isovalent has been brief, it has proven to be very useful using simple name tags for securing communications instead of IPs and ports. Additionally, at Layer 7, it allows configuration based on FQDN, making Cilium a flexible choice for defining secure rules.

Creating policies with Isovalent has been easier as it employs YAML files for configuration, which aligns well with those familiar with native Kubernetes deployments. It also features Layer 7 rule creation, which I find beneficial, evolving with capabilities such as eBPF for enhanced observability with gRPC, providing granular insights into clusters through Cilium.

Isovalent has positively impacted our organization by enabling control over communications restrictions in microservices, an essential feature since Kubernetes defaults to allowing all pod communications, addressing crucial cyber security concerns and helping implement a zero-trust model, which aligns with our cyber team's requirements for security benchmarking and auditing.

While I have not extensively used Isovalent products or Cilium, I have not identified areas for enhancement as of now.

Regarding how long I have been working in my current field, specifically in the telecom domain, I have been working for 16 years, 12 years of which were spent in a public sector undertaking, and currently, I have been working for the past three and a half years in Tata Elxsi.

Isovalent has been stable based on my experience.

Regarding Isovalent's scalability, our product has not been tested at scale in a real production environment with massive scalability needs, but in local setups where pods spawn and auto-scaling occurs, Isovalent Cilium product remains stable.

We did not interact with customer support for Isovalent or Cilium, as we used their open-source tool.

Prior to adopting Isovalent, we utilized various CNIs that I find less evolved compared to Cilium, which is a product from Isovalent.

Isovalent is deployed in our organization using both on-premises settings and AWS cloud through EKS, allowing us to utilize both public cloud and on-premises infrastructure.

We did not interact with customer support for Isovalent or Cilium, as we used their open-source tool.

I can state that we have experienced smoother audits post-implementation of Isovalent, successfully addressing primary auditing requirements. Financially, we have not documented a return on investment since we utilized their open-source Cilium product.

I did not have the chance to explore pricing, setup costs, or licensing details, as we switched to a different product and telecom services post-creation, and I have not used Isovalent since.

Before choosing Isovalent, we evaluated other options, including Weave Net, albeit theoretically without implementation in a Kubernetes cluster.

We did not purchase Isovalent through the AWS Marketplace.

On a scale of 1 to 10, I would rate Isovalent an eight, reflecting my short interaction of three to four months where it facilitated easy integration with our existing clusters, particularly for our use case where tagging microservices was straightforward.

I chose that rating as my experience involves implementing Isovalent for one product, and its ease of execution greatly aided our processes; however, I deducted two points because I have not explored their other products or fully implemented routing and BGP capabilities, which I have only encountered theoretically.

Regarding Isovalent's capabilities, I think its governance and security features are its main advantages, particularly the control over communications achieved through better name tags and FQDN URLs, which I have observed. Theoretically, I see governance and performance being tackled concurrently. I find its accuracy and reliability of output quite commendable, especially for our use case where we are able to maintain control over our intended traffic.

To others considering Isovalent, I would definitely recommend it, emphasizing the control over internal pod communications achievable with the well-evolved Cilium, and the ease of rule setting which does not necessitate network expertise. Appropriate naming tags can enable effective functional isolation across services. My overall rating for Isovalent is eight.

I am not currently using Isovalent, but I first discovered this technology approximately four or five years ago on LinkedIn. During that time, I developed interest in the technology and tried the hands-on lab on my own, though I am not using it in my current company at the moment.

My main use case for Isovalent when I tried it out personally was to explore how container networking capability can be extended further via Isovalent eBPF technology. The hands-on experience gave me a deeper understanding of how things work under the hood.

I was mostly curious about the technology, so when I went through most of the lab, I personally experienced how the features of Isovalent were deployed, managed, and how I could operate it. Currently, I do not have anything else to add about my use case or my experience exploring Isovalent, but I feel that the product is great with many features.

In my opinion, one of the best features Isovalent offers is its firewall, which I believe is called Tetragon. This allows us to specifically block connections between one namespace and another, giving us more control over how traffic is allowed within the Kubernetes cluster.

I found the process of setting up and managing those firewall rules to be somewhat challenging because it was new to me. However, after reading documentation and going through trial and error methods, things worked accordingly.

Isovalent positively impacted me by increasing my exposure to new technologies. Previously, I was only exposed to technologies such as NGINX, traffic into Kubernetes, and more of the native CNI plugin of Kubernetes based on the cloud service provider. Isovalent demonstrated a new way of doing things, and from the news I have read, many cloud providers, especially Microsoft, have already adopted Cilium in their AKS deployment.

Learning about Isovalent changed the way I approach cloud security in my day-to-day work. It highlights that security should be applied from the top to the bottom, and I believe Cilium plays a crucial role in filling that gap.

Based on my experience, Isovalent's documentation is great, the hands-on experience is excellent, and the badge given to people who tested the hands-on is very valuable. I do not have any suggestions for improvements in these areas.

I have not explored Isovalent's AI capabilities in terms of governance and security, so I cannot comment on that aspect. I have also not explored Isovalent's AI capabilities regarding the accuracy and reliability of output, so I do not have any insights there either.

I have been working in my current field for approximately six to seven years, and I have been with this company for almost four years.

In my experience, Isovalent has been stable. I did not discover any issues while testing it.

I do not have thoughts on Isovalent's scalability because I have not fully tested that particular aspect.

I have been self-guided through documentation and labs regarding customer support, as I had no experience with it.

I did not switch from any different solution for container networking or network security. Instead, I explored what kind of technology is available.

Isovalent is deployed in my experience as part of hands-on labs, and I plan to deploy it in my own personal cluster in my home lab.

My home lab is entirely on-premises, running on my five-year-old laptop.

I have not seen a return on investment from my experience with Isovalent, so I do not have any comments on that.

I have not gone through the specific details of pricing, setup cost, and licensing for the hands-on lab.

Before choosing Isovalent for my hands-on experience, I did not evaluate other options, as I used the default setting of that on-premises cluster.

I would rate Isovalent an eight on a scale of one to ten. I chose that number mainly because of the hands-on experience that provided me with a tear-down cluster that I could test, view, and experience without spending any resources or deploying any resources on my laptop.

I think spending some time to experience the hands-on lab with Isovalent is exciting and useful. I believe more hands-on labs would be helpful. My overall review rating for Isovalent is eight out of ten.

Isovalent has a Network for Kubernetes platform that we use, and our whole cluster is integrated with their dashboard. It is quite easy for us to use for networking purposes. We get a good UI to see all the networking that is happening on our cluster, which is very useful.

The major component in our case is the service mesh and the Networking for Kubernetes platform that Isovalent provides. We have a Kubernetes cluster running, and one of our services has the whole mesh deployment as well, where we use the Ambient Mesh feature that Isovalent provides, which also has Cilium eBPF features.

The main part is the networking itself. Isovalent has the eBPF feature that they provide, through which we can look at the ground level of networking to see exactly what is happening on our cluster. They provide all the hooks in the UI itself, which is one of the positive points that I feel we have.

Apart from their networking, they also have a project called Hive, which is an eBPF-based project that is quite useful. They have their own service mesh called Ambient Mesh, through which they use Cilium. Cilium is their product, so they provide features with Cilium, and the mesh part is quite useful.

Their eBPF feature is quite awesome. I appreciated it because we can look at the very depth of networking to see exactly what is happening there. I think people should use it more.

In my case, there are two things. The security part has improved quite a lot, and troubleshooting has also become quite easy. They have a very good UI through which we can easily see all the networking that is happening. That is what we are achieving for now.

The documentation is good, but they could improve in that area. Someone who is new to networking might feel daunted going through all those detailed materials. They could have high-level documentation first, and if anyone wants to deep dive into any areas, they can read more on that. They could segregate the information in the documentation.

Documentation is one of the major areas for improvement. Apart from that, the product is quite good. I love it, and everything is good.

The AI features are okay. They are still researching and improving in that area, but the guardrails are good, and everything works as expected for now. However, I think it would be good if they improve in that area.

I would not say it is 100% correct. Sometimes it does hallucinate, but overall it is good.

I have been using Isovalent for the last one and a half years.

The setup is quite easy. It is easy to set things up. However, sometimes I feel the costing is a bit high, on the higher side. That is one of the things that Isovalent has.

There was an instance where there was a traffic spike on a product, and there was some lag. As traffic increased, we saw that there was a bit of lag in the way the product was reacting. Initially, we were not able to find the issue, and we tried other things, such as checking the network tabs and using Wireshark, but eventually, Isovalent came into the picture and really helped us verify exactly where the bottleneck was. We were able to fix it.

Isovalent is a quite good company, and I love their products. I think they are already doing their best, so I do not feel there is any need for improvement already.

Everything is good. I just want them to keep improving and making their product better day by day.

In our case, it was time-saving because the dashboard is quite good, and we were able to find quite a lot of bugs in our system. I would rate this review a 10.

We wanted to migrate from Calico to Cilium because we wanted to have an alternative CNI for our Kubernetes cluster to use the in-built eBPF native kernel path for better observability, a better network experience, L7 policies, and other benefits.

I was looking at all the features provided by Isovalent so that we could migrate from Calico. I was using it as an overall product to replace Calico rather than tackling a specific use case.

I have created two different Kubernetes clusters on bare metal. I added Cilium from Isovalent as the CNI and then created a service mesh between both clusters using Cilium. The clusters work fine, and the pods from one cluster to another are automatically communicating using the eBPF native data plane rather than IP tables. The routes and everything are set up by Cilium service mesh automatically. It was a good overall CNI to set up the multi-cluster setup, and I use Hubble to see the traffic pattern and how the traffic moves from one cluster to another.

The eBPF feature from Isovalent allows us to have the data plane used rather than IP tables and the traditional IP table lookups. Hubble, which is their observability tool, gives end-to-end visibility in the Kubernetes cluster, showing how the traffic flows. These aspects really help to troubleshoot issues. These two features are the best ones, and the design for cloud-native applications makes it better than the traditional CNIs currently available. The L7 policy implementations, service mesh, and these other features are pretty good in Cilium.

My experience with Hubble involves its capability to run a trace, and there is also an in-built UI provided by Hubble. I can use both of these tools to see how the traffic moves from one pod to another pod. In case my pods are crashing, for instance, in a multi-cluster setup where pods are not communicating with each other and applications are dropping, I can check within Hubble to understand why this is happening. I can use it for end-to-end visibility.

Using Isovalent's Cilium, I have seen that it will be really helpful for the design and implementation teams who are actually building this cluster and providing it to the end users. Their work is positively impacted as they can solve things quickly and serve better applications. In cases where applications are failing inside the pods or have issues, they can trace problems better using Hubble and the other features that Cilium provides. Since eBPF is the core of Cilium, I have a better data plane, and I am not relying on traditional IP tables. Consequently, the end-to-end visibility and data path performance enhance the overall experience, which makes it a better product.

I believe Isovalent has everything we need right now, and I cannot comment on what features they should add. However, if they can tackle and showcase more end-to-end use cases to the audience using online platforms like YouTube or other formats, they can represent their ideas better. Sharing end-to-end use cases that can be achieved using Cilium would be great for people to look into and then apply to their specific use cases.

I have used Isovalent for a year.

I would advise others looking into using Isovalent to start with a POC to see what they offer. If they want to integrate it into their network, they should ensure they have end-to-end visibility for the problem they want to solve, and then they can use it to address their issue. It is a good product overall, and if anyone is looking for some cloud-native integration for Kubernetes clusters from the CNI perspective, I think it is a good solution.

My main use case for Isovalent is creating a solution using EBPF, which is responsible for security and monitoring the requests in the cluster because Isovalent helps with security in the solution.

I use Isovalent to create monitoring in the requests between pods. For instance, when pod A requests something from pod B, I can monitor that using Isovalent because Isovalent uses EBPF in the background to monitor layer three and layer four in the cluster.

Isovalent is a great tool to create security and monitoring in the environment's security.

Isovalent offers many features.

Visibility stands out the most to me because I can see all requests between pods in the cluster.

Isovalent has positively impacted my organization because my clients really appreciate this solution. Isovalent delivers security, visibility, and scalability, which are very important for my clients.

The implementation of EBPF in the environment has led to an improvement in security and visibility in the metrics.

Isovalent can be improved with a new feature using AI because AI is a great tool and is used extensively.

Additionally, the interface is very important to me because the user does not have the ability to see how Isovalent is working. It is mostly a line of code, and a user interface is very important, as I consider it a great feature for implementation.

I have been working in my current field for two years.

Isovalent is stable and it is not confusing.

Isovalent's scalability is great, as I use Isovalent for one to many users connected.

Isovalent can handle a large number of users connected at the same time. I use it to show my clients that many clients are connected in my solution, and it is working very well. It is not laggy and it does not freeze the solution.

Isovalent support is great and very helpful.

Isovalent was my first time using this solution.

My experience with pricing, setup cost, and licensing is that it is very easy because Isovalent is simple. I can manage pricing and setup cost for my clients, and for the license, I buy Isovalent.

I have seen a return on investment, principally in time saved, because I invest considerable time creating and developing the solution using Isovalent. For me, it is a very important return on my investment.

My experience with pricing, setup cost, and licensing is that it is very easy because Isovalent is simple. I can manage pricing and setup cost for my clients, and for the license, I buy Isovalent.

I did not evaluate other options before choosing Isovalent. It was my first choice.

Isovalent is deployed in my organization in the public cloud, specifically using AWS. I would rate this review a ten out of ten.

I have been using Isovalent on and off for the better part of the last four years, initially starting as a hobby project and now in some production environments where I use it for specific use cases primarily on-premise designs.

My main use case for Isovalent is the network framework and as a CNI for Kubernetes-based architectures, additionally integrating with network policies and some of its other more low-level networking capabilities, primarily brought about as part of the merger with Cisco or acquisition by Cisco. It provides and has almost become the de facto standard for the networking control plane in a Kubernetes environment.

Regarding my main use case with Isovalent, it boils down to some of those key features that are added, providing networking across environments that can serve as a standardized networking stack across both on-premises and cloud environments. On top of that, I have very granular controls from a security standpoint. I can start using Hubble and identify what the flows look like. I have that full observability of networking real-time traffic across services running in my clusters. Then I can use that observability to enforce security policies and ensure I am only communicating with what I need, both on the east-west and north-south side.

Using Isovalent's Hubble alongside Tetragon has been really powerful in terms of identifying threats and ensuring I can enforce compliance and regulation from a network and cybersecurity perspective. The integration with all Isovalent tools across Cilium, Hubble, and Tetragon provides a very intuitive and clean design that makes it convenient to adopt in specific environments.

Although I am not actively using it, some of the best features Isovalent offers are its service mesh capabilities, which are incredibly powerful and do not come with the traditional complexity that something like Istio traditionally offers. Having everything under one umbrella, the Isovalent umbrella, is very beneficial in terms of reducing tool sprawl and helping my team become familiar with one software suite instead of having to balance and jump around between different types of software. Isovalent becoming the de facto standard has already made it a good tool to adopt because there is wide community support. Even things like Gateway API were adopted very early. The load balancing and network visibility are features I go to a lot, and those are all very helpful and beneficial features that I can use on a daily basis.

I find myself relying on the visibility aspect of Isovalent the most day-to-day, probably because in many cases, I may not know all the services being deployed, and this provides that high-level observability to see which microservices are communicating with each other and whether I want them to communicate. If not, I can enforce policies.

Isovalent being that standardized networking tool across all my environments has positively impacted my organization because I no longer need to spend too much time balancing effort maintaining different systems. Everything provides this centralized common ground that everyone can become an expert on.

The only feedback I have about Isovalent is probably to lean on more documentation from the resource perspective, which is amazing. I would say that there can be some additional support on the AWS side of things in particular. There is much better support with Azure and GCP, however. In particular, some of the documentation could be tailored towards specific use cases.

The documentation in general has been improved significantly over time.

I have been working in my current field for about seven years.

Isovalent is stable.

I have had no problems at scale with Isovalent's scalability.

I have not leveraged customer support directly; I leverage the community support through GitHub and other channels.

Before Isovalent, I used the CNIs that were part of the cloud provider experience.

In some environments regarding standardizing on Isovalent, I encountered the opposite situation because, for example, in AWS, they prefer that I use their VPC CNI. There were some initial configuration challenges with that. Once the framework is established, things work out of the box.

I do not have raw data regarding the return on investment with Isovalent; however, from a time saved and fewer employees needed perspective, I can definitely see benefits in the sense of fewer people needing to have operational maintenance time.

My experience with pricing, setup cost, and licensing for Isovalent was outside my area directly, as I have a dedicated team that handles those matters.

When I had to evaluate other options before choosing Isovalent, I considered only Cilium because I knew it was becoming the de facto standard.

One of the reasons I initially adopted Isovalent was the community support and push for education. The labs that Isovalent creates were a huge way to introduce me to the platform. Working with people like Raphael Pinson was really great to see. I can tell that they care, they look for feedback from the community, and they want to build a great product.

The advice I would give to others looking into using Isovalent is to follow the standards that are placed and not try to deviate too much from the recommendations, and they will have a good experience.

I have no additional thoughts about Isovalent before wrapping up; I would encourage continued innovation and ongoing improvements. I would rate this product an 8 out of 10.

My main use case for Isovalent primarily involves network choices and network options. When my clients requested a Kubernetes migration from either on-premises or some cloud solutions, we designed a Kubernetes ecosystem. I have finance companies as clients that require more secure and faster communication at the network level, which led us to review and choose Isovalent products for our Kubernetes ecosystems.

As for a specific example of how I used Isovalent for one of my finance clients, one of my clients is a fintech company with significant traffic every day, every minute, and every second. Network consistency and network monitoring are very important in this field, and Isovalent utilizes eBPF solutions in some of its products such as Cilium. We use Cilium, and its kernel-based operations and monitoring are very good, demonstrating how the network features made a difference.

In my experience, the best features Isovalent offers are mostly found in its products, particularly Cilium, which we have been using for around three years and is a very good feature on Isovalent's side.

What stands out for me about Cilium is that it offers observability, security, and integration with Kubernetes. I think all of them are significant advantages.

Isovalent has positively impacted my organization by ensuring that after moving to Isovalent products, we trust the tools we chose for the community, particularly the powerful tools such as Cilium. We are very confident in how our network and network tools are performing. The easy management provided by Hubble view in Cilium is excellent for quickly checking if we miss some points. The configuration is very clear and is supported by many third-party services, and that is very good for us.

I am not sure how Isovalent can be improved as they are doing very well. I know their developer teams and sometimes discuss new features and abilities, but as of now, they are progressing well, and their new features seem good.

I have been using Isovalent for maybe three years, as three years ago, we chose Isovalent products and applied them in our ecosystem.

I have not seen any specific outcomes or metrics such as a reduction in troubleshooting time, improved uptime, or cost savings since using Isovalent.

I do not know what advice to give to others looking into using Isovalent, as I am not sure right now. I do not think there is anything you should change for the future. My overall review rating for Isovalent is nine out of ten.

I have used Isovalent for the networking certification, which is an open source certification.

Visibility and performance are a big positive side for Isovalent. The work environment setup is valuable because it is easy to understand.

Isovalent is easy to use and very fast to set up all the things.

If I had used other tools instead of Isovalent, it would take maybe one or two days. However, using Isovalent will reduce your time and it completes within one to two hours.

I have not experienced any stability issues with Isovalent.

Isovalent has better customer support. While I have faced some issues regarding the setup things, they have helped me immediately. The customer support is better.

I would rate the customer support of Isovalent nine or ten.

I have not used any other solutions for networking certification tasks.

For the question purpose, I don't have to use any other command line tool. I can directly use the Isovalent tab to solve this problem and give the solution for the questions.

I will definitely go straight with Isovalent.

There is a big opportunity to explore Isovalent, and I have really had a very great experience with it.

Our company is not able to use Isovalent because they are using SharePoint Power Private Limited. I don't think they will use it.

I find Isovalent easy to use, so I would rate it eight or nine.

Isovalent is totally free.

I would definitely give the advice to use Isovalent because it is easy to use and easy to set up all the networking environments and the other things.

I do not have any additional thoughts about Isovalent at this time.

Cilium is my main use case for Isovalent. Cilium is our primary use case for our AKS cluster, so every part of our solution is using Cilium right now and we are hosting it for more than a million users.

The specific Cilium features that stand out to me the most include the eBPF-based networking, which is a big advantage for networking, load balancing, security, observability, and everything. Hubble is also a valuable feature. The network policies, Gateway API, and Ingress support are also quite significant.

I also appreciate the transparent encryption between nodes and workloads.

Isovalent can continue improving their features. I do not have anything specific regarding Cilium at this time.

I have been working in my current field for four years.

Isovalent is stable.

The scalability of Isovalent is good.

The customer support for Isovalent is great.

I previously used Kube-proxy, which was the regular AKS solution. Now I am using Cilium with AKS, which is Azure's Cilium solution.

My advice for others looking into using Isovalent is to start with a small proof of concept before rolling out. Test the features, have observability, network policies, and everything in place. Ensure there is a lot of training involved.

Before choosing Isovalent, I evaluated other options and determined that it was the best in the market.

The best features Isovalent offers are the various Cilium features.

We had a workshop with the Isovalent team which showcased how you could implement Cilium and what it could bring to the table, not only in terms of security but also observability. We were convinced and implemented it.

We have noticed reduced incidents as a specific outcome that shows how things improved. I would rate this review an 8.