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.

Positive

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.

Positive

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.

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.

The event timeline has been super helpful, enabling us to overlay node events in the same timeline as deployment events. For example, if your deployment goes down for some unknown reason, the event timeline overlays if there was a node that may have had disk pressure or some other issue. That helps an engineer very quickly troubleshoot without having to do too much digging.

Komodor also recently put in an investigation or triaging window. When we first started using it, you really had to dig to find out why things failed, or you had to set up availability monitors to give you some of that information. But now, straight from the event timeline, you can click on a little red icon that indicates that something failed and it gives you a best-effort summary of what it thinks failed, just by looking at the different statuses. They try to trickle the most important things up to the top, while still allowing you to scroll down and dig deeper. That's a very nice feature.

There is also the ability to show differences between deployments. We annotate all of our deployments with some of the Komodor labeling schemes: specifically, the Git repository and Git hash. That way, you can click on any deployment in Komodor and it shows a quick summary of what changed. Sometimes there is only a change in the application code because the base image didn't change. Sometimes, neither one has changed and it's just the deployment descriptor. But we had one problem not too long ago where the engineers and our support team spent a couple of hours troubleshooting. Komodor highlighted a change in the base image, which ended up being a breaking change.

Being able to quickly see those changes is very helpful. That's a valuable feature and shows that having historical information like that is super important.

Another useful feature is the logging. You lose pod logs in the Kubernetes dashboard or if you are using kubectl on the command line. You can't see logs of pods that have been deleted, but Komodor retains them for a small amount of time. If you do a deployment and it gets rolled back and the pods are gone, Komodor still grabs some of that, and you can use that for troubleshooting. That is also a nice feature.

Having an agent that's almost God-like makes us a little nervous. I would love to see the actions not be performed on behalf of the user, but rather as the user, perhaps by aligning SSO groups, as one approach to that. That is one reason that we're not using its actions, because we're a little nervous about granting all that access to Komodor. In terms of just read-only and presenting this data, you have to give it view access to practically everything to get value from it.

Also, we get a steady stream of new users coming into Komodor, so I know people are using it. But one thing we don't have visibility into, which I would love to have, is metrics, such as user logins and usage. It's really hard to know what people are doing when I don't have any metrics on that directly.

If somebody higher up wants to know how Komodor is being used over time, I can't query that. I know that Komodor has those metrics, but from my understanding, they're in another tool outside of the Komodor application. It would be nice if they found a way to funnel that back in. Currently, Komodor doesn't really focus on the managers and decision-makers when it comes to the engineering of the tool. They rely on quarterly meetings where they present usage but it would be so much nicer if that was built into the tool. 

They're also working on the audit log area and there is still a long way to go to make that look nicer and more feature-rich.

We went live with Komodor about a year ago.

It definitely has lots of moments where it's lagging, even for what seems like a very small window of time and a small number of events. It can be a head-scratcher as to why it is taking so long.

Ever since we've been using it, there have been little issues here and there, and to their credit, they've been fixing them. It used to be if we left a tab open the whole tab would die after an hour or so. They may have been trying to load too much data in there and that may have led them to a design decision where now it takes a long time to query all the data because they don't want to overload the tabs. I'm not sure about that, but it does lag intermittently and not very predictably. Sometimes it's screaming fast, and sometimes you wonder why it's taking so long. We've had multiple people comment on that.

The source of the lagging we see could be because it's not scaling very well. We have a whole bunch of clusters and a ton of nodes, and it might seem that on the surface it's handling it, but maybe it's not. But I don't have the correlation to say whether it scales well or not. 

There is a shared Slack channel, so I would call that support. And there is a Help feature in the app itself. Their support is very responsive and they get back to us right away. I've never had anybody as responsive as they are.

Positive

The better visibility was the main reason we switched to Komodor. Being able to visualize changes to deployments on a timeline is something that our previous solutions did not provide at all. That historical aspect of Komodor is helpful. We never had a tool that could help with a node event and a deployment going down.

The initial setup was very straightforward and painless. It was all done in-house. It was just a Kubernetes deployment, a Helm chart, and it was very quick. It was just me involved on our side, our SSO support, and there was somebody involved on the Komodor side. There were other people involved in the proof of concept, giving input and feedback.

There is no maintenance, other than that I have to redeploy the Helm chart whenever there's an update. Because there are updates so frequently, I do that about every month or so.

During the proof of concept, I did a lot of things, such as annotating from our deployment tool and correlating the deployment to changes in Git, which was a super big deal. During that time, the solution wasn't live for any of the users, so we couldn't have seen any value at that point.

But pretty much right when we went live and presented it to the users, they were happy immediately. And every time we've shown it for troubleshooting in our support channels, and we show a screenshot, people always say, "Wow. What tool is that and how do I get into it?" It has been nothing but a delight for all of our engineers from day one.

We did a scour of the internet for open-source solutions around the whole landscape of Kubernetes tooling. But we never really found anything else that was compelling.

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.