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
Top 20
2023-05-23T19:17:00Z
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
Top 10
2023-03-16T14:00:00Z
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 is the missing piece in your DevOps toolchain - offering one unified platform from which you can gain a deep understanding of all of your system events and changes. We integrate with all of your tools, monitor changes and alerts and organize information on a clear digestible dashboard and provide you with the right context at the right time.
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.