Komodor helped me solve issues faster because it has a unified dashboard and a centralized troubleshooting platform. Using that platform, I was able to detect the issue and solve it. I rely mostly on root cause analysis in my daily workflow because when something bad goes into production, I should know why the pod is crashing or why there is an outage or what is killing my container. Root cause analysis is something I rely on most. For example, if I were taking half an hour to solve an issue, it is now done in ten minutes, so I think fifty to sixty percent of the time has been reduced. I think Komodor adheres to policies and is really secure, and its capabilities help me analyze things without using my data to read something. I am using AI to detect issues. I would rate Komodor an eight overall.
My advice for others looking into using Komodor is that it helps you quickly find a root cause in Kubernetes without guesswork. That is my belief regarding its effectiveness.If you have many services, frequent deployments, and constant changes, Komodor will be a great solution for understanding the root cause when something goes wrong. You can see all the changes in a timeline, figure out the crashes, reduce the time investment in understanding problems, and minimize the need to jump between different log tools. I would rate this product an eight out of ten. Therefore, I recommend choosing Komodor.
I would like to add that there are other features in Komodor as well. Whatever application teams need, all the features in Komodor are available for visualizing the Kubernetes environment, so not just one feature but everything is helpful for application teams. My advice for others looking into using Komodor is that if their main intention is for 100% availability for their application teams, Komodor is completely suitable for their needs. Overall, Komodor is a very good platform for managing Kubernetes-related infrastructure, and as of now, my experience with Komodor is very positive. I would rate this review a nine out of ten.
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.
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.
Senior SRE at a computer software company with 501-1,000 employees
Real User
May 23, 2023
We have a whole bunch of steps just to onboard somebody into Kubernetes, and Komodor has nothing to do with that process. Even after an engineer has deployed Kubernetes, they still haven't really learned anything about Kubernetes, but Komodor allows them some visibility into things without having to know too much about their deployment and their logging. However, the learning curve for Komodor is super low. We just tell people, "Go here," and their reaction is "Wow." And if somebody asks a question on one of our support channels, our support engineers will use Komodor to find something, send a screenshot and a link, and people will say, "Wow. What tool is that? That's really neat." We generally don't have to teach anyone at all to use Komodor. We did a presentation or two when we first went live with it, but we have had a ton of new users since then, and we never get questions on how to use the tool. Everybody is very happy with it. Regarding the Komodor Helm Dashboard feature, that used to be a whole separate service and we were not interested in investing our time and energy into deploying it. They have since integrated it into Komodor and it is very helpful, but don't know how much our users use it. Our product engineers aren't necessarily aware of the Helm layer. They don't really know that their deployment is actually six or seven different Kubernetes resources. They don't really see things that way or know all the different pieces of the puzzle. Some of them do, but not all of them, and they're not required to know that. Helm is important from the support side, for myself and other support engineers. But the only time, even on the support side, that we need to know anything about Helm is when we need to uninstall something. If we don't want to delete the deployment resource, we need to do Helm uninstall. The Helm dashboard is interesting, but it doesn't really solve anything for us. And that's by design. We want things to be as simple as possible for them. We don't want them to have to know what all these things are. My advice would be don't overthink it. It was so easy to onboard. It's definitely worth it in the long run. I was heavily involved at the beginning, getting us onboarded with Komodor, but the great thing about it, and this speaks volumes about the organization and the product they have made, is that it does a great job running itself, and the users are very happy with it.
DevOps Engineer at a retailer with 1,001-5,000 employees
Real User
Mar 16, 2023
If you want to build a container solution in-house or leverage open source tools, you really need to think about the components you put into your in-house solution. Open source tools can definitely give you an edge in terms of the ability to look behind the scenes. You can get really far with open source products. If you are considering using Komodor, my advice would be to try it out. Then, you'll be able to see what it can do and be convinced that it is the way to go. Overall, I would rate Komodor at eight on a scale from one to ten with one being the worst and ten being the best.
Komodor offers enhanced visibility and centralized event timelines for Kubernetes environments, enabling efficient debugging and proactive management across multiple clusters.Komodor provides a comprehensive platform for troubleshooting and monitoring Kubernetes deployments. It aids in root cause identification, deployment notifications, and tracking historical changes while maintaining real-time metrics and retained logs. The platform supports efficient CI/CD pipeline management and...
Komodor helped me solve issues faster because it has a unified dashboard and a centralized troubleshooting platform. Using that platform, I was able to detect the issue and solve it. I rely mostly on root cause analysis in my daily workflow because when something bad goes into production, I should know why the pod is crashing or why there is an outage or what is killing my container. Root cause analysis is something I rely on most. For example, if I were taking half an hour to solve an issue, it is now done in ten minutes, so I think fifty to sixty percent of the time has been reduced. I think Komodor adheres to policies and is really secure, and its capabilities help me analyze things without using my data to read something. I am using AI to detect issues. I would rate Komodor an eight overall.
My advice for others looking into using Komodor is that it helps you quickly find a root cause in Kubernetes without guesswork. That is my belief regarding its effectiveness.If you have many services, frequent deployments, and constant changes, Komodor will be a great solution for understanding the root cause when something goes wrong. You can see all the changes in a timeline, figure out the crashes, reduce the time investment in understanding problems, and minimize the need to jump between different log tools. I would rate this product an eight out of ten. Therefore, I recommend choosing Komodor.
I would like to add that there are other features in Komodor as well. Whatever application teams need, all the features in Komodor are available for visualizing the Kubernetes environment, so not just one feature but everything is helpful for application teams. My advice for others looking into using Komodor is that if their main intention is for 100% availability for their application teams, Komodor is completely suitable for their needs. Overall, Komodor is a very good platform for managing Kubernetes-related infrastructure, and as of now, my experience with Komodor is very positive. I would rate this review a nine out of ten.
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.
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.
We have a whole bunch of steps just to onboard somebody into Kubernetes, and Komodor has nothing to do with that process. Even after an engineer has deployed Kubernetes, they still haven't really learned anything about Kubernetes, but Komodor allows them some visibility into things without having to know too much about their deployment and their logging. However, the learning curve for Komodor is super low. We just tell people, "Go here," and their reaction is "Wow." And if somebody asks a question on one of our support channels, our support engineers will use Komodor to find something, send a screenshot and a link, and people will say, "Wow. What tool is that? That's really neat." We generally don't have to teach anyone at all to use Komodor. We did a presentation or two when we first went live with it, but we have had a ton of new users since then, and we never get questions on how to use the tool. Everybody is very happy with it. Regarding the Komodor Helm Dashboard feature, that used to be a whole separate service and we were not interested in investing our time and energy into deploying it. They have since integrated it into Komodor and it is very helpful, but don't know how much our users use it. Our product engineers aren't necessarily aware of the Helm layer. They don't really know that their deployment is actually six or seven different Kubernetes resources. They don't really see things that way or know all the different pieces of the puzzle. Some of them do, but not all of them, and they're not required to know that. Helm is important from the support side, for myself and other support engineers. But the only time, even on the support side, that we need to know anything about Helm is when we need to uninstall something. If we don't want to delete the deployment resource, we need to do Helm uninstall. The Helm dashboard is interesting, but it doesn't really solve anything for us. And that's by design. We want things to be as simple as possible for them. We don't want them to have to know what all these things are. My advice would be don't overthink it. It was so easy to onboard. It's definitely worth it in the long run. I was heavily involved at the beginning, getting us onboarded with Komodor, but the great thing about it, and this speaks volumes about the organization and the product they have made, is that it does a great job running itself, and the users are very happy with it.
If you want to build a container solution in-house or leverage open source tools, you really need to think about the components you put into your in-house solution. Open source tools can definitely give you an edge in terms of the ability to look behind the scenes. You can get really far with open source products. If you are considering using Komodor, my advice would be to try it out. Then, you'll be able to see what it can do and be convinced that it is the way to go. Overall, I would rate Komodor at eight on a scale from one to ten with one being the worst and ten being the best.