Isovalent Reviews

The main use case was using Cilium as a CNI for our Kubernetes cluster, so we used it for network policy and observability via Hubble, primarily for our CNI for the Kubernetes cluster.

My responsibility was to implement and set up a Kubernetes cluster, and one of the things we had to choose was CNI. We had several options, one of them was Cilium, because it is eBPF based and operates at a kernel level performance, giving us better performance. After we set up that with Cilium CLI, it was somewhat difficult to set up, but afterwards, we could solve problems with the observability we had with Hubble UI. I remember one time we had to find out what the problem was between two microservices we had, and we used Hubble to understand what the problem was.

I can speak about the way we use Hubble mostly because it was really different compared to what other tools I used before for observability at the network level. It gives us exactly what all the packets are using in this cluster and what happened between microservices. I remember the latency we had between two microservices, and we could solve it to understand the main debugging we could do for that. It was also better when I read about the internal level of Cilium that uses eBPF, not using IP tables, giving us better performance because we used a two regions cluster. It also gave us native support for L3, L4, L7 network policies, allowing us to manage the policies between microservices.

The thing that made Cilium different compared to other CNIs was that it is eBPF based, because mostly others used IP tables, and IP tables is not very fast compared to eBPF. The other thing is Hubble, in my opinion, gave us very good observability on the whole traffic in our cluster and provided us with a better debugging version we could use, because normally for debugging network problems, it is really hard.

First of all, we wanted to use Flannel for our development environment, and we can say Flannel was fine enough, but when we used Cilium, we understood we could obtain more internal debugging knowledge that we needed. We had more knowledge and a higher observability level of all the packets, which gave us better performance too, because it was an exchange company needing lower latency and fast transactions. After we changed the CNI from Flannel to Cilium, even in the dev environment, we got better performance, approximately 20% better, and because we used Prometheus monitoring, we had accurate data about our performance improvements.

Regarding features, I can speak about the docs, which were very good regarding deep networking and the internal workings of Cilium, but sometimes I think they could be better, specifically for best practices. Some parts need improvement in including best practices for each section, such as upgrading or implementing it, because I had some problems with setting up with Helm, and then I used Cilium CLI. Then I understood Cilium CLI is the same as using Helm, so that was beneficial, but the docs of Cilium could be better.

I think the assumption for the readers is that they have really good deep knowledge about networking, but sometimes, in my opinion, to share something with that good performance and those good tools, we need to make it simpler to teach others about eBPF. I read the book about eBPF shared on LinkedIn, and it was a good book, but we can make it simpler by sharing best practices and conducting interviews with users about how they utilize that, making it easier for everyone to start and understand. Improving the documents is important.

I remember when I set up the Hubble UI, there was a bug, but it is already fixed because when I updated, it was resolved. The bug was when I implemented and set up Cilium CNI, Hubble could not run, but after I upgraded the Cilium version, it was fixed. For improvements, having some tools for debugging eBPF at the kernel level could help. I know we have those, and I use them, but a better UI for that would be beneficial. Also, the documentation can be better and more straightforward, perhaps offering two versions—for those who want to learn more and for those who just want to implement with less focus on the deeper networking aspects.

I would rate Isovalent an eight or nine because almost everything is fine, with very good quality and support in the open-source community. However, as I said, the documents can be improved, and as a DevOps engineer, I always look for best practices to set up or configure something easily. While best practices are environment-based, there are some default best practices that could be highlighted somewhere to make it much easier for others to set up these tools.

In both companies I worked for, Invex and Norvan, I used Cilium, the CNI for our Kubernetes cluster, so I have worked with that for approximately two years.

In my opinion, during the two years we used it, we did not have many problems with Cilium. There was an issue with the initial setup on-premises, but once configured well, it operates very smoothly with minimal problems.

The scalability is very good.

We handled two clusters in different regions with many nodes, around 20, facilitating connections between those nodes and the pods, which numbered more than 200. Regarding customer support, since I used the open-source version, not the enterprise version, it was very fine. I remember asking questions in Slack, and the community was active, responding in a decent time.

Since I used the open-source version, not the enterprise version, it was very fine. I remember asking questions in Slack, and the community was active, responding in a decent time.

We did not use Flannel for long but made a short shift to Cilium in the dev environment. In production, we used Calico for some months, but we switched to Cilium due to performance benefits, as we wanted to focus on understanding how to choose something based on future needs to outperform our competitors in the market.

My responsibility was to implement and set up a Kubernetes cluster, and one of the things we had to choose was CNI. We had several options, one of them was Cilium, because it is eBPF based and operates at a kernel level performance, giving us better performance. After we set up that with Cilium CLI, it was somewhat difficult to set up, but afterwards, we could solve problems with the observability we had with Hubble UI. I remember one time we had to find out what the problem was between two microservices we had, and we used Hubble to understand what the problem was.

We evaluated Flannel, Cilium, and Calico, and based on those experiences, we chose Cilium due to its superior performance and better observability provided by the Hubble tool.

If you have a good product needing high performance and visibility into your network at the cluster level, I suggest giving Cilium a chance. You will understand the great observability of Hubble and the performance benefits of eBPF, especially when you compare it to IP tables and see how it reduces the complexities of IP table rules.

The open-source community is active and robust.

If you have a good product needing high performance and visibility into your network at the cluster level, I suggest giving Cilium a chance. You will understand the great observability of Hubble and the performance benefits of eBPF, especially when you compare it to IP tables and see how it reduces the complexities of IP table rules. I would rate this review a nine overall.

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.

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 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.

My main use case for Isovalent is using Cilium policies together with good visibility on the internal AKS traffic. For example, I use CDM policies and visibility for internal traffic in a scenario where Grafana Loki components are using different configurations inside the Grafana Loki deployment.

The best features Isovalent offers include excellent experience for traffic observability and a lot of nice features related to security hardening for Kubernetes deployment.

Unfortunately, I do not have any use case for those security hardening features for Kubernetes because this was only my testing and I have not implemented that on a production scale.

Isovalent has positively impacted my organization by increasing efficiency. The increase I noticed is the efficiency of the support teams. Isovalent helped my support teams be more efficient by decreasing time consumption related to troubleshooting for network-related issues.

I experienced some Hubble problems which were related to the huge internal traffic, which was somehow causing Hubble to hang and required a restart of Hubble. That is something that could be improved.

I have been using Isovalent for around four years.

Isovalent is stable. In my experience, Isovalent is stable and there has been nothing problematic as far as I am aware.

I have not seen any performance issues related to Isovalent products, so I am guessing it is good regarding scalability.

I do not remember right now about the customer support but have not had many support cases open for Isovalent products.

I did not previously use a different solution.

I think the return on investment question is not the best for me because if the metric includes decreased time of support related to network issues for the deployed applications, then fewer employees are needed from the support team. This is the biggest return on investment.

My experience with pricing, setup cost, and licensing is that it was not a big issue to configure.

I have not evaluated other options before choosing Isovalent.

The advice I would give to others looking into using Isovalent is that the biggest advantage from my perspective is that you can easily track what communicates with what, and this will give you a much better overview of what needs to be allowed in a secured and hardened environment.