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 also use Komodor's integration with Pager Duty to proactively monitor our Kubernetes infrastructure. It is an important part of our overall Pager Duty monitoring.

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.

The most valuable aspect is the speed with which I can narrow down what's going on. Usually, I look at the overview of events and then the timeline of an event and the status of the logs to quickly check what's happening or what has happened. There is also a new feature of metrics so that we can see if we did not provision enough resources, and that's why there were issues. Overall, what is valuable are the troubleshooting workflows.

The metrics are a real-time feature, and I look at them to see how the node is doing and whether it is using all the assigned CPU and memory.

The part I like the most about historical data, and what I use most, is the timeline. You can see everything on the time axis and make sense out of it. With a job event, pod event, or node, you have everything lined up rather than querying the Kubernetes cluster by hand or looking at many different logs. That's the main historical feature.

It's a little hard for me to assess how easy or difficult it is to learn Kubernetes using Komodor because I learned it without Komodor. But I can tell from my colleagues who have very little understanding of Kubernetes but who work on the underlying network setup. They were able to troubleshoot with Komodor without an understanding of Kubernetes. They were able to troubleshoot lower-level network issues. So it's definitely way easier than without Komodor, but I'm not sure if it's actually easy.

Onboarding new developers to Kubernetes using Komodor is fairly quick. Once they have a general concept of clusters, nodes, pods, and jobs and understand the process that is actually running on Kubernetes, it's fairly easy. They can find their way around the product and find the information they're looking for.

There's nothing in particular that is wrong with Komodor. It's hard to say that there's something we would really like to see improved.

I hope that the cost analytics and resource usage allocation areas will see further development. For example, where we can now see if the pods are over- or under-provisioned, I wouldn't mind higher-level development.

I would like to see if we're utilizing nodes in the cluster, if pod allocation is optimal, how much idling we have, and whether we scale up and down efficiently. I would like to see them help us optimize costs further. Because, as our company grows and our clusters get busier and busier, any inefficiency is a lot of money wasted. That's definitely high on our wish list: anything that helps us track wasted resources.

I am looking forward to using AI-powered troubleshooting workflow that Komodor unrolled recently.

I have been working with Komodor for about two years and a half.

We haven't had any issues. Even when they said, "Hey, could you update the client because now it will be more stable?" We didn't notice instability. It's stable.

It's scalable.

Komodor is very responsive to our company's feedback and what we would like to see.

Their support is very responsive and friendly. Our relationship with anyone from Komodor is very good and enjoyable.

The deployment is very simple. It lines up on Kubernetes. And even though we have a special way of deploying our products securely, it's not an issue. The deployment is quite trivial. It was mostly done by one person.

We tested everything outside of production and gave access to a group of people for evaluation. It was pretty fast. It's so easy to implement that, other than the testing we had to do to make sure it didn't destabilize our system, there wasn't all that much to do.

We have about a dozen users. Anyone from the team that directly works with Kubernetes can have access.

In terms of maintenance, Komodor releases updates to their client. They recently heard feedback that updates were happening too often, so they slowed down the frequency at which they ask you to update. And sometimes there are new features you need to configure, but that's a good thing.

We haven't calculated ROI explicitly, but it's definitely worth it.

Realizing the benefits happened fairly fast. It took days and weeks. We had a test deployment, and the benefits were pretty obvious. We had quick access to the tale of the logs of crash pods, et cetera. The value comes pretty fast once you deploy it.

We're not done with our onboarding. We plan to embed it more into our processes, to have it embedded with PagerDuty, et cetera. There are some benefits we have yet to cash in on.

We did look at other options, but we're happy with Komodor. Other options pop up, but Komodor's pricing works well for our use case. It's fair, and we appreciate it. A lot of other vendors price their solutions in a way that would cost us disproportionately more money than they should. Komodor's pricing is reasonable in the way they calculate usage and value.

If someone wanted to build a container solution in-house or leverage open source tools, it would cost them a lot of money. Maybe some of the biggest software companies in the world can afford that, and it's worth it for them, but for a company like ours—and we are not a small company—it still makes sense to buy rather than build on our own.

My advice is that Komodor is just easy. It's worth trying, and there is a very low cost to trying it. You shouldn't shy away from giving it a try and showing it to developers and anybody who is interested in knowing about both the underlying cluster as well as the applications that run on top of it.

You should have an understanding of how much time you spend troubleshooting and how many people actually have access to Kubernetes. Is it a closed environment that is a black box for developers? Analyze and be aware of the problems you actually have and how things could look better, in terms of usage of Kubernetes, in the ideal world. Komodor will help you get there.

Everything is easier in Komodor than using Kubernetes on its own. I can see the changes in the solution and how the product is getting easier to use, even over the relatively short period that we have been customers. I can see improvement and that it's getting more and more user-friendly.

In terms of the effect of Komodor on our longer-term strategy for digital transformation or cloud migrations, it is a bit early to tell. We haven't made any decisions yet about moving more of our computation onto Kubernetes, but Komodor definitely makes it easier. The argument that Kubernetes is difficult to understand isn't as strong. It removes barriers, but so far, it has nothing to do with Komodor or Kubernetes. We just haven't had an opportunity to make those changes. We haven't discussed it. But I'm quite confident that it would help us favor Kubernetes.

I give Komodor a strong eight out of 10. It's growing. I know it will go higher.

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.

Komodor's multi-cluster centralized event timeline is the most valuable feature. With it, I can have a single pane of glass view of all my clusters at once, and see a timeline of all events.

I have used Komodor for two and a half years, and it has come a long way. However, I would say that performance could be improved. Sometimes, it takes longer than it should for developers to pull up logs or interact with the cluster. Komodor is aware of this issue and is working on a fix.

Secondly, I like the alerts that Komodor provides, but I think the alert interface could be improved. It is not the most intuitive system in the world, and it can be difficult to set up. I think Komodor could improve the alert interface by making it more user-friendly.

Finally, I would like to see Komodor add ServiceMaster visibility. This would give us greater insights into how our services interact with each other. This would be very helpful in troubleshooting problems, as it would allow us to quickly identify which services are affected when one service goes down. Komodor does not currently have this capability, but I hope they will add it in the future.

I have been using Komodor for almost three years.

I give the stability an eight out of ten.

I have used the solution in both a large organization and a small one, and it has not had any scalability issues. We have 100 people that use the solution.

I give the scalability a nine out of ten.

I work directly with Komodor's product team. We meet every other week. If we need support, we have a shared Slack channel where I can ping them whenever we have an issue. Issues are almost always resolved within 24 hours, if not within hours.

The only issue I've had with technical support is their availability during certain times. They are based in Israel, so for our West Coast team, it can take until the next day to receive a response, depending on the overlap between our working hours. Therefore, the only real issue is their time zone availability.

We used a combination of different tools, including Prometheus, Datadog, Sologic, and Grafana. We also used manual Kubernetes commands and cube ETL commands. Komodor combined five or six observability tools into one, which was a big selling point for us. It replaced our need for a separate tool for logs, metrics, and alerts. We still use our manual Kubernetes commands and cube ETL commands, but we can use Komodor for 95 percent of our work.

Komodor's initial setup is straightforward. It is one of my favorite features of the product. All you need to do is install a Helm chart. That's it! There is no additional setup required. The deployment took 15 minutes.

The implementation was completed in-house.

The return on investment is excellent. The biggest factor in the ROI is the reduction in developer hours. We are replacing Datadog with Komodor, which is cheaper and offers similar functionality, but with some additional features. This will save us money in terms of the cost of the subscription, as well as the time that developers spend troubleshooting issues. In addition, Komodor's self-service capabilities will free up our operations team to focus on other tasks. Based on our estimates, we will save enough time in the first month to cover the cost of the subscription. As a result, we expect to see a positive ROI within the first year of using Komodor.

The licensing model is fine. It is per node, which is good, but the pricing is high. Currently, I am fine with it, but I am a little concerned about the pricing as we scale. So, it is on the higher end. On a scale of one to ten, where ten is the most expensive, Komodor is a seven.

We evaluated a number of other options before choosing Komodor. At the time, there was no other tool on the market that did everything Komodor does. We found a variety of tools, both on the vendor market and open source, but they all only offered a few of Komodor's features. We were looking for a centralized product that offered all of the features we needed, and Komodor was the only one that met our requirements.

Since then, a few competitors have emerged, including StackState. We don't like StackState as much as Komodor, but it is a competitor that offers similar features.

I really like StackState from an operations view because it has that service mesh feature. Komodor works really well for operations, But my favorite part of Komodor has been the developer enablement, and a huge part of that is how nice the UI design is and how intuitive it is to use. I don't have to teach all my developers how to use it. StackState is great, but it is not intuitive. It's not easy to use. So it would not be a great fit on the developer enablement side.

I give Komodor a nine out of ten.

If someone is comparing Komodor to open source tools, my biggest point to them would be that open source tools can work well, but they will have to maintain multiple different tools from multiple different vendors to get the features that they get with Komodor in a single solution. So, it is up to them how many tools they want to manage. We made the decision to move from a large stack of open source tools to a single one because it really helped with our ease of management. We no longer have to manage so many different services. Komodor is self-service. A lot of those other tools we bring in-house require a lot of work to scale and upgrade, but Komodor we don't worry about it. The solution is dead simple, and I've never had to do any kind of maintenance with it. It just works.

I have used Komodor in two organizations. In my first company, it took five to six months for Komodor to be fully adopted by developers. This was because Komodor was a new product, and the company was still working on it. In my most recent organization, Komodor was adopted within less than a quarter. This was due to a number of factors, including the fact that Komodor was now a more mature product, and the company had a strong focus on developer productivity. A big part of Komodor's success in my most recent organization was its self-service capabilities. This meant that developers could easily get started with Komodor without having to rely on IT support. If we had really sat down and implemented Komodor and evangelized it, we would have seen a return within the first three months.

The maintenance is simple. We update the Helm chart once a quarter, which takes five minutes. Komodor is deployed across all of our locations.

First, take inventory of the observability that their current existing products, both open source and vendor, provide. Then, try Komodor, which is incredibly easy to try out, and see what it replaces. I would also suggest involving their developers in the evaluation process. When we evaluated Komodor, we treated it as an operations observability tool, not a developer-enabling tool. However, it has since morphed into being a developer-first and observability-second tool because it is so helpful. Therefore, make sure that both operations and developers are involved in the trial.