Komodor Reviews

We use Komodor for two prominent use cases. The first is from an operational standpoint. It is our number one troubleshooting tool for our operations teams. The second is developer enablement. We use Komodor to allow developers to interact with their Kubernetes clusters, get alerts, and see what is going on without giving them direct access to Kubernetes. It is very helpful.

The historical data is part of the event timeline. It is hands down the best feature I have seen in terms of providing preserved data, such as what has happened and what has changed. It is very useful. The real-time data is especially useful for our developers. In real-time, they can go in and see the logs of their pods, see what is happening, and see the status of their services. This is very convenient for them.

Komodor's ease of use was one of the reasons why we chose the solution. I am very technical and know Kubernetes very well. My director is not technical and struggled quite a bit. However, he logged in to Komodor and within minutes, he understood what was going on and was able to interact with the cluster. This was something that I had been teaching him manually for weeks, but he struggled with it. He was able to learn it by himself in minutes.

We just started using the Helm dashboard, and it has been very helpful. We can now easily pull the cluster, view all the Helm charts that are installed, and see their statuses. We use the dashboard to check values, and it has been a great addition to our workflow. There is no other tool that does this, so it is very convenient to be able to see all of our Helm information in a single GUI. The biggest benefit for us is how quickly we can move between Helm charts and dive into them.

Komodor has significantly improved our organization. The biggest benefit for me and my team is the amount of self-service it provides our developers. They no longer have to ask our operations team for help with any problems or questions. Historically, any problem or question in the cluster had to go through our operations team, as we were the only ones with the knowledge of how to fix it. Now, I would say 90 to 95 percent of those requests no longer come to our team. Developers are able to self-service. This has saved us probably 10 to 15 hours a week, if not more, for a team of four people. The self-service that Komodor gives us frees up my operations team to actually do work and not handle requests. This has been a big boon for everyone involved.

Komodor has had a massive impact on our day-to-day operations in two ways. First, it has freed up developers by allowing them to self-service their needs. This means that they no longer have to wait for the operations team to resolve issues, which allows them to spend more time developing and working on projects. Second, Komodor has saved a significant amount of time on troubleshooting. In the past, if there was an issue, we would have to dive through logs and look at five or six different tools to try to pinpoint the problem. This could take hours, but with Komodor, it now takes minutes. Komodor is a centralized timeline that brings everything into a single spot. As a result, I can now open Komodor and quickly find the source of the problem, which used to take me a lot of time jumping through different tools. Overall, Komodor has had a positive impact on our day-to-day operations by freeing up developers and saving time on troubleshooting.

Komodor has had the biggest impact on our developers. For the operations team, it has definitely sped up our process. But for the engineering team, it has given them the ability that they did not have before. They did not have insight or the ability to interact with their services. Adding Komodor has completely freed that up, and now they have direct access to their applications in our clusters, which they did not have at all.

We do not use the event log frequently, only when we need it. However, every time we have needed to refer to the audit log to see what has changed, it has been very detailed. It is exactly what we need and it works very well.

Komodor's event timeline is its number one feature. It is everything, really. It allows any operations person or developer to log in and see what has changed in the cluster in a centralized view. Historically, with Kubernetes, this has been very difficult because there are literally hundreds of log places that would have to be checked. Komodor centralizes all of this into a central place, and it is also multi-cluster, which is something that no other product on the market does. This saves a huge amount of time.

Komodor provides extensive visibility into our nodes. The events themselves bring all of the individual log places into one place, which is very helpful. However, when it comes to visibility, there are two main features that I really enjoy. One of them is the multi-cluster aspect. In my previous role, we used Komodor to manage forty-plus clusters. If an application changed, we had to go through each cluster to see what was affected. In Komodor, it doesn't matter how many clusters we have. It's all centralized. So if we roll an application to 40 clusters, I can see that impact immediately across all 40. This has been a huge help. The second biggest feature is the service dashboard. Our developers can immediately open up the dashboard to see if their services are helping. If they're not, they can dive in and see why. And the best part is that once they're in there, they can set their own alerts. They don't need to involve the operations team in that. So the next time there's a service disruption event, they can be notified immediately.

Komodor has become our number-one tool for any incidents or even any questions. We used to have to go to multiple tools to find the information we needed, but now we can just open up Komodor and take a look. It's our number one visibility tool. On the operations side, Komodor saves us about eight to twenty-five hours a week for a four-person team. On the development side, it saves each of our forty developers three to five hours a week. Overall, Komodor has been a huge time-saver for our team. It's a valuable tool that we would highly recommend to anyone looking for a way to improve their incident response and troubleshooting capabilities.

Komodor has been incredibly useful in freeing up our DevOps staff for other projects. Previously, we spent 30 to 40 percent of our time dealing with Kubernetes, troubleshooting requests, and diving into the platform. Now, that number has dropped to five percent because our developers are able to handle those tasks. This has freed up our operations team to focus on actual DevOps projects, rather than just being a ticket center.

Komodor has had a huge impact on our development velocity and end-to-end ownership. Historically, developers would write their application and then hand it over to the operations team to deploy Kubernetes and monitor it. This was mainly because developers did not have the ability to see what was going on or interact with it. Now, developers can do the entire process themselves. They can develop their application, deploy it to Kubernetes, and then immediately pull up Komodor to see the status of their application. If there are any issues, they will receive alerts directly. This means that developers can now own the end-to-end process of development, from development to deployment and monitoring. In the past, developers would develop their applications and then send them to the operations team. They would then sit and wait until the operations team could deploy it and get back to them with the results. This process was slow and inefficient. Komodor has significantly sped up the development process by taking the operations team out of the loop. Developers can now self-service and develop and deploy as fast as they want. They no longer have to wait on a secondary team to assist them with tasks that they are capable of doing themselves.

In the long term, we are building a culture of service ownership. At our organization, we are trying to move away from being a small startup where developers need a lot of help. We want to be a much larger, scalable organization where developers can self-service and are not dependent on one team. Komodor plays a key role in this, as it enables us to scale our engineering organization on the developer side without having to scale our operations time as much. It is one of the key essential parts of our development and engineering organization's scale.

We are an HR analytics company, and we do a lot of data processing. Our customers send us their HR-related data, and we process it so that we can run analytics on it. We process it on Kubernetes clusters, and we use Komodor to monitor our clusters to ensure that the clusters are reliable, to troubleshoot them, and to optimize the setup to make it cost-efficient for us.

My usage of Komodor may be a bit unusual because I go into it to troubleshoot or monitor something. I usually go in with a specific goal of looking at something via Komodor, so I use the workflows more than the dashboards. Either I'm running some process and want to monitor it in Komodor, or there is an incident and I want to find out what's going on via Komodor. I also look at the dashboard, and I can see at times that something does not look quite right. That's useful.

We are definitely saving time using Komodor. We can troubleshoot much faster.

We can also share access to Kubernetes with more people, which relates to the ease of onboarding. More people can directly look at Komodor and look at metrics. They have access to the information in a secure way. For example, teams that are not responsible for the system but run processes on the clusters can look at their usage of resources. That's very beneficial because it means fewer questions and less work for us as the team responsible for the system.

Komodor has made it easier for the development team, which is responsible for the platform on top of which we build our application, to "own" the Kubernetes cluster and be responsible for it. That makes our SRE team's life easier because they don't have to deal with something they don't understand very well.

We can give more end-to-end ownership to less experienced developers. We don't have to train them or give them more access to our system. It definitely speeds up development quite a lot because we know we will be able to see it in Komodor. It speeds up application development somewhat, but it also speeds up the Kubernetes maintenance or changes we are making to our cluster. We can iterate faster.

It also definitely gives us cost insights. We could get the information that we get from Komodor, but it would take a long time. You would have to get it from many sources, and the data would not be overlaid on top of each other to make sense. By combining all the information coming out of Kubernetes, Komodor makes it easier for you to see the information and what is going on. That makes everything much faster.

You also discover things you wouldn't have noticed otherwise.

Komodor is very helpful when it comes to using event logs to create an audit trail. It's a basic security requirement. All of our processes are compliant because we know who changed what, in an efficient way. We had a similar ability, but the experience for the person modifying the system was pretty bad. It was slow. We couldn't give people direct access to the Kubernetes cluster. Now, they have direct access via the UI, but we have an audit log and security.

Before, something that would take me 15 minutes to half an hour to investigate via logs and kubectl using the CLI controller, or forwarding our logs to Splunk—which requires much more knowledge—I can probably investigate in five to 10 minutes now. It cuts the time by three-fold or even more. And I'm more likely to actually find the answer. If you try to troubleshoot Kubernetes via logs, but you had such issues that even logs weren't forwarded from the cluster, such as your application logs, then you have no logs. With Kubernetes, for instance, we don't go via Splunk. We go directly via Komodor. That cuts out one middleman.

I'm very happy with the overall visibility that the solution gives me into our nodes. It's intuitive, and I can find all the information I want. That visibility helps save time when troubleshooting. It cuts it to 10 or 20 percent of what it would otherwise take. But it's not only that. Even if I could get this information, I'm not sure I would be able to make sense out of it, and that would take longer. The chances are I would miss something. Because it's providing it in a user-friendly format, there are higher chances that I will actually understand what's going on or see something. It's not only about time, but also the effectiveness of how the information is presented. It's not only the fact that it's much faster, it's also that I'm actually successful in finding what I need or understanding it.

We use the solution for troubleshooting and for our Kubernetes resources.

The historical and real-time data provided by Komodor is great. I can go back and look at the data from the previous week as well as the data coming in real-time.

Our developers are immediately aware of when their microservices have been deployed, as they can see who deployed it and what was included in the deployment from the commits. It is therefore essential that we are notified of each deployment and know immediately what has been deployed. We also receive notifications when a deployment fails. This is very important, as a developer may start a deployment process without checking if it has been completed, and the notifications inform us immediately if something has gone wrong. We needed the ability for our developers to manually trigger some of the applications running on Kubernetes, and Komodor provides us with this capability. Additionally, it is great that they have a permission system, so I can create a team that can trigger specific jobs and others. Komodor also has notifications regarding any issues with our nodes or cluster, so it is sometimes useful for the infrastructure team to be alerted.

Komodor can correlate events and pinpoint issues quickly.

Komodor reduced our mean time to repair by around half an hour per developer due to the fact that they no longer need to contact the infrastructure team. Before Komodor, we had to reach out to someone else and wait for a response before proceeding with the checks to determine the cause, but now the developers can figure it out on their own.

Komodor helped save our DevOps team ten percent of their time.

We didn't have a very good story for our product engineers to help them visualize their application, post-deployment after migrating from Singularity to Kubernetes. Singularity has a nice user interface where they could see the deployments and scale, balance, restart, et cetera. When we moved to Kubernetes, things were more hidden. All we had was the Kubernetes Dashboard, which is verbose and clunky. We were looking for something to help our engineers visualize their deployments and troubleshoot them.

Our engineers currently deploy through our CI/CD system, and it's fire-and-forget. We report back the status of their deployment to them, "success" or "fail." So visualizing things across deployments, and seeing the events—what changed—really helps our engineers with troubleshooting, especially when we have an incident.

The biggest benefit is that our triage time decreases extremely when people choose to use Komodor. If there is a failed deployment, hopping into it to see the logs from the pods is very quick and easy. When a deployment is crashing and people don't understand why, Komodor is the quickest way to comprehend all the different pieces of the puzzle in one place and figure things out.

But it's not just that. Komodor does its best to give you what it thinks is the root issue. I'm not sure when this was added, but when there is a failed deployment, it even inspects your log stream and narrows it down to the line in your logs where it thinks the root cause of the failure is. I was pretty impressed with that. For example, where there were a lot of Java exceptions being spat out, it zeroed in on the right one.

The visibility into nodes has helped save time when troubleshooting in cases such as disk pressure, memory pressure, and seeing why pods have been evicted. The way that node events are overlaid onto the event screen really helps correlate what is happening and why it's happening.

In terms of freeing up staff time, I was one of the main people involved in setting Komodor up. And now that it is up and running, I've been able to work on other things. The questions we get in our support channel have decreased quite a bit when it comes to Komodor.

For our product engineers who are doing a deployment, and everything is falling along the "happy path," meaning the deployment is successful and there are no issues with it running, Komodor is not part of that engineer's life. Where it really shines and helps is when there is a problem. It eases the burden of troubleshooting.

We have a multi-cluster setup with a lot of workloads being distributed throughout those clusters. Komodor is installed on all our clusters as a base component. We wanted an easy way for operations staff who are not as experienced to be able to look into what might be wrong with workloads across these clusters.

We're fairly new in the sense of taking Kubernetes in as an orchestrator for workloads. We ran workloads using a Docker host previously. Komodor has given us a fairly easy way to obtain a good overview.