Splunk Cloud Platform was very useful for us. With the on-prem setup, we had to maintain all the servers and take care of the upgrades, whereas with Splunk Cloud Platform, we did not have to bother about that. Everything was handled by the Splunk support team.

It was sufficient for us to monitor multiple cloud environments. The visibility that it provided into multiple environments was good.

We used Splunk Cloud Platform for business processes and security. It helped us a lot. On the business side, as a banking organization, it was helpful for reports and alerts. On the security side as well, Splunk was helpful. We could see any security breach. It was also helpful for smooth operations. If any issue happened or any server was down, it automatically alerted us.

Everything is maintained by the Splunk support team. Users do not have to maintain any physical servers. They do not have to maintain indexes and searches. It reduces a lot of work on the user side.

We integrated it with other applications in our environment. It integrates well. We did not face any issues on the integration side.

The reporting offered by Splunk Cloud Platform is also good.

I faced a few minor issues with Splunk Cloud Platform. In the case of knowledge objects, even a Splunk admin does not have access to delete them. If we want to remove a knowledge object, we need to contact Splunk support and raise a case. After that, they delete it. They should give us access to delete knowledge objects.

Everything else was good. It already had all the features. We did not require any new features.

I used this solution for almost ten months in my previous organization. Currently, I am not using it. I last used it about five months ago.

It was stable. We did not see many issues. Any issues were on the physical servers, not on the Splunk Cloud side.

It is scalable. We had more than 2,000 users in our organization. It was being used by more than 150 departments.

Onboarding end-users was easy. I was a Splunk admin, and I was also an end-user. I could provide access to other end-users directly.

Their technical support was good. I would rate them a five out of ten because we worked in the Australian time zone, and the tech support team that we usually got did not have much knowledge. They took time to resolve issues.

In our organization, we used multiple products. We had Dynatrace and other products, but we mostly preferred Splunk. It was more user-friendly than others, and we could search everything easily. We could create dashboards. Other products were more difficult.

It took us a long time to switch from on-prem to the cloud. It took almost four to five months.

We took the help of the Splunk team for migration, but after that, we did not take their help. We took care of onboarding and other things. It was easy. If any issue came up, we contacted the Splunk support team.

I do not have much idea about the price. We previously used 1 GB at the cost of $600. Both on-prem and cloud licenses have the same price. There is no difference.

It did not impact the cost because the costs of the on-prem license and the cloud license are the same. We did not have any issues with that. Overall, its price is reasonable.

I would recommend moving to the cloud because you do not have to maintain physical servers and infrastructure. Everything is handled by the cloud provider.

Overall, I would rate Splunk Cloud Platform a nine out of ten.

I use Splunk on my phone, on-premises, and for the automation tasks that we carry out.

We use it to work on dedicated forms and infrastructure and have a lot of virtual machines and instances that are being run for every single application. Our infrastructure is purely based on Azure by Microsoft.

Keeping CMDBs of all the virtual machines is a heavy task. When you use it for your portal use, it might be two or three virtual machines. When a virtual machine is created, we use post-provisioning inside the virtual machine. While post-provisioning, we install Splunk agents so that any activity that is happening inside the VM is virtually monitored by Splunk.

We create a dashboard. We are able to monitor everything from that dashboard.

Splunk also offers enhancements and automation. Splunk plays a major role when it comes to automation. We extract the data from Splunk, and then we use it to automate using a jump server so that we can put in actions on any number of virtual machines.

The automation is the main advantage. When we need to search for data, as engineers, it's very easy.

I like that it's an independent cloud platform. It can work with AWS or Azure.

Its monitoring is completely automated. We do not have to put in other engineers just to maintain Splunk. It maintains itself, and it's very user-friendly. For the dashboards to be created or any sort of code that we want to do with Splunk, we can do it by ourselves. We do not need to have separate resources so it is very cost efficient. We do not require many people; it's resource-efficient as well.

We do use the federated search feature and find it helpful. Earlier, it was hard to withdraw data. We'd have to maintain it. Now, Splunk does it for us. It's a very time-efficient service. It's made a huge impact on automation. We can grab data in real-time any time we need to.

The solution integrates well with other applications and systems in our environment.

It could have a more efficient UI. If they could integrate more AI and make search more efficient so that other people can access and use it, not just engineers, that would be ideal.

It needs to mature; it's just getting established in the industry on a wider scale.

The API still needs some enhancements from a post-performance point of view.

From a monitoring point of view, Splunk is doing very well. However, if they could provide a post-provisioning aspect. Right now, we have to install a monitoring tool while we are post-provisioning every virtual machine. If they could be a provider that precluded having a virtual machine being created or provisioned, that would be ideal.

Alerting could be faster. Sometimes the actions that happen take some time to reflect on the Splunk dashboard. There is still latency. Especially when you work in a multi-cloud environment, you deal with a lot of regions. They still need to focus on availability across regions.

They need to have some security enhancements. Most users are using it with other single sign-on features like Okta. If they had their own SSOs that would be ideal. we'd be able to work independently. Right now, we have to log onto the virtual machines then move to Okta, then go to Splunk.

I've been using the solution for somewhere around a year or one year and a half.

The stability is okay. Sometimes it goes down. I have not witnessed that as I do not use it continuously after the deployment. The resiliency is good. I'd recommend it four out of five.

Everyone in the company uses Splunk.

The scalability is very good. It's extendible.

I don't directly deal with technical support. We have a dedicated team that would work with Splunk.

Generally, my understanding is that if we have a query, we raise a ticket. There may be a separate portal or mailbox we can access as well to get assistance.

We previously used Qualys. We switched mainly due to the costs involved. We also didn't want to migrate our resources to it. We simply wanted a monitoring tool, which is why we chose Splunk. Splunk in comparison is really cost-efficient.

I was involved in the deployment of the solution.

Whenever a new resource or a new agent comes into the picture, in an organization, it's always complex. I don't blame Splunk for it, or my firm. It's like two pieces of a jigsaw puzzle and it's the developers who need to cut the pieces. It works really well as of now.

The deployment took somewhere between six to eight months.

We did need a lot of resources or staff members for the deployment. We have a vast infrastructure. We have a dedicated team inside as well who manage incidents and tickets using platforms like ServiceNow, and we still have a lot of resources dedicated to maintaining Splunk. The number of resources that are required to maintain it is more than the number of resources we use for development, actually.

How many people you need depends on the region. I work for Asia and North America. So for us, it was not much personnel. We needed four to five people in the development. There were somewhere around ten to fifteen people working on different parts.

About 90% of the deployment was handled in-house.

I'm only aware of general pricing terms, however, they have enterprise agreements as well. I can't speak to the exact cost. It's reasonable, from my understanding. I'd rate the affordability seven or eight out of ten.

Evaluating other options would be a task reserved for the highest management personnel at our firm. I was not involved with that process.

We aren't using the solution across all cloud platforms. We use Azure. However, we would have the flexibility to gather insights from others. We just don't use that particular capability.

Right now, the solution does not affect our decision-making. It's still a very new platform. We're not relying on it completely. It's a work in progress. We need some time with it, to build up trust with it. Splunk is great so far, however, we still need more time and it needs more of a presence in the market.

Right now, in terms of compliance and privacy policy regulations, we limit the features that are not compliant with us. However, they are very flexible. We just use the features we can and block the ones that are unnecessary.

It hasn't had an impact on our security posture. We have very detailed security layers and several processes and teams. We haven't had any real use cases for Splunk. It hasn't actively blocked anything. We already have what we need in place.

I'd advise new users to check if this solution is reliable from a security point of view. Talk to Splunk about the cost as well. Splunk is really convenient for that. And whenever you deploy it in your infrastructure, make sure that the cloud providers or the on-prem solution that you are using are compatible with Splunk. We had issues in that some features that we were using in the cloud were not compatible with Splunk. So we had to make a lot of changes. That is something anyone who is trying to deploy Splunk needs to check - compatibility.

I'd rate the solution seven out of ten.

We collect almost everything that we log and push it into the Splunk Cloud Platform. That is pretty much our use case. It is mostly for our cyber monitoring tool, firewalls, normal cyber logs, Windows event logs, etc.

Splunk Cloud Platform has helped improve our organization's business resilience a little bit. It is a big organization, and I am just a little part of it. Its impact on the whole business has been a little bit.

We use ES for correlation, incident handling, and things like that. It reduces the mean time to resolve a little bit as compared to the other SIEMs that we were using. We are not using SOAR right now, but that is where we want to be.

I like the fact that we do not have to maintain all the cloud infrastructure. That is probably the main thing about the Splunk Cloud Platform. We do not have to worry about maintaining the infrastructure that is out there. We just push things up and maintain our infrastructure on-premises. This is important for us because we just do not have the manpower and resources to manage all the infrastructure.

We used to use another SIEM with which we constantly had to replace hardware and things like that, so it is a good benefit to have that cloud infrastructure there whether it is coming from a SaaS environment or we just build it in the cloud.

One thing that is a stickler for us is the ability to download apps. I guess it depends on what kind of license you have. It allows some of them if I want, but this is something that we need on a day-to-day basis. When one of my customers needs an app, and I am able to find that app on the Splunk base, I have to create a ticket and wait for five days for them to download the app into the cloud environment. That is probably one of the main things. It is painful because I have to wait to get that app in the cloud.

Another issue is that if I build my own app to some configuration, I cannot load it up there myself. They have to vet it, which is important but it takes a long time to do all that.

We have been using this solution for a little less than one year.

It is very stable.

Scalability does not apply to our environment. Because it is a cloud, scalability is relative to how much you can afford. It scales itself if your data increases because it is a cloud environment.

Splunk's support is very good, but because the cloud environment was pretty new, I ran into a couple of stumbling blocks with the support for the Splunk Cloud Platform. However, it started to get a lot better. Currently, it is a lot better than when I first started. At that time, a lot of the support staff was probably new to the whole cloud environment, and I realized that. We were the first DOD department to go into the cloud, so it was tough in the beginning with their support. I would rate them a nine out of ten.

We were using ArcSight. The decision to switch to Splunk did not come from me. It was the decision of the company itself. It was a requirement. We could not track the up/down status with the other SIEM. Splunk can do that better. That was one thing.

Another thing was the way Splunk can put things like MITRE ATT&CK into their platform. The way it handles rules and things like that makes it a lot better with the processing power. Splunk is search-based, whereas ArcSight is real-time. It fires the minute an event comes up, whereas Splunk has a separate way of doing it. They run a search every hour or so. It is not resource intensive. A lot of times, I can only turn on a minimum amount of rules, especially correlation rules, in ArcSight. I used to have about 300 or so in ArcSight. I probably have about 400 or 500 in Splunk, so the hardware processing power is a lot better.

I was involved in its deployment. Its complexity level was 50/50, but that was expected because of the lack of training initially. We had an awesome team from Splunk that helped us out. They were there for us for at least a month. They helped us and then trained us on the environment. By the time they left, we were good to go.

The return on investment is not in a monetary sense. Things are a lot less stressful in our environment. We are able to see things that we were not able to see before. It gives us a little calm because we know if something is up or down. We are able to see things that we could not see before in other SIEMs. So, there is a reduction in the stress level.

We have seen a time to value. I can do plenty of things a lot faster than I could previously.

We evaluated Sentinel, QRadar, and LogRhythm. All of them were very good SIEMs, but we had a lot of challenges when it came to getting them certified on government L5. IBM has its own private cloud. They do not use AWS. We did not have that issue with Sentinel, but it is not as robust. Even though it is at a high level in terms of industry-level SIEM, it could not meet our requirements. It is still a challenge. Sentinel is the only one that is a competition to Splunk if you talk about cloud, not on-premises. It is native to the cloud.

It is awesome. I love it. Anything is possible in Splunk. I have gone through a lot of challenges with use cases. When I needed to figure something out, I got it resolved sooner or later. I either got Splunk support or I went to the community and looked it up. I have never run into anything that I could not do with Splunk. It is very good.

Overall, I would rate the Splunk Cloud Platform a nine out of ten.

We're migrating our on-prem environment to Splunk Cloud Platform. We're consolidating two separate Spark clusters because of a merger. Our primary use case is for unifying all of that data into one place.

It's made searching for data easier. Users like it. We're still in the migration process, but overall, it's a lot easier to use.

It's important to use that Splunk has end-to-end visibility in our native environments. We have to have that visibility because we manage multiple app applications that rely on it.

Splunk helped to improve our organization's business resilience. That's very important to us. Our users rely on Splunk heavily for the health of their applications. It helps them to get ahead of issues, and if there is an outage, it enables them to resolve them faster.

Splunk gives the different application owners the ability to configure alerting specific to their needs so they can customize it however they want. If they know their applications better than you know, admins, I'll give them that flexibility.

The administration could use improvement. We have to rely on support more often than we're used to.

We have been using Splunk Cloud Platform for nine months.

Stability has so far been good. We haven't had any issues.

Their support is great, especially the agent that we have now. They're very responsive, willing to help out, and give suggestions.

We previously used Splunk Enterprise. We switched to Cloud Platform because we wanted to consolidate a couple of instances to one place and we're moving our security team to the cloud.

I wasn't involved in the setup directly but I was aware of what they were doing. The setup is a little complex. We had some issues we had to deal with. Bringing both environments together and getting the different environments to communicate with Splunk Cloud was complex. We have a lot of data. Getting a handle on that before we were able to start sending data to the cloud was complex.

It's expensive. We're still trying to figure out Cloud licensing.

It's not so easy to monitor multi-cloud environments using Splunk. We have some difficulties, but we have some things in place, but it's not easy.

I would rate Splunk Cloud Platform an eight out of ten. There's a lot we haven't tapped into yet, so the rating can go up.

We are primarily using it for InfoSec, cybersecurity intelligence, information gathering, and forensics. We also do a little bit of application performance monitoring for some appliances that can only be monitored through log ingestion.

We are starting to monitor multiple cloud environments. We have our internal cloud, and we are migrating to AWS. We are engaged in that path. In terms of monitoring, it is more or less the same because we are using the same integration pattern, which is to use Ivy folders and gather logs. We use it at its minimum, but the way I see it at the Splunk conference, we can go further. Will we go further? That is a million-dollar question.

It has end-to-end visibility into our cloud-native environment. For sure, it is important for operation and application support, but we need to embark our staff and management for that. They are the ones who are committing big dollars to that.

It has not reduced our mean time to resolve because we are using other tools as well. We are aiming to go on that path in the coming months.

It specifically has not improved our organization's resilience. There are a myriad of modern tools that we are implementing. Splunk is one of them. It is one of them helping us.

Index Manager is most valuable because we do not have to bother about internal storage. It is all managed by the Splunk team.

The security connection should have a seamless integration. Other than that, the way we are using it, so far, it seems quite good.

We have owned Splunk Cloud Platform for the last year and a half.

The stability of the solution is quite good.

We had challenges with the sizing of the cloud tenant that we purchased, but that was based on past decisions, so we are stuck with that until our next move. That should come in the next year. At that time, we will resize the tenant in a more efficient way, so scalability does not apply because the tenant we bought is a closed one. There is no scalability on either side. I learned that after the fact, so I am not impressed because we did not buy it. I guess people who buy that type can have good feedback on scalability.

We migrated from an on-premise solution that we had for about three years. We saw cost efficiency when we went from on-premise to the cloud, but I do not manage the budget.

We are using Dynatrace in parallel. We used Splunk as a cybersecurity tool, and we embraced Dynatrace a few years ago. So far, Dynatrace does a great job. Splunk is closing the gap. With today's announcement at the Splunk Conference, they are catching up. We are also using Microsoft SCOM, so it is a trio. It helps us do a better job.

I was not involved with the setup of the on-prem one, but I was involved with the migration to the cloud. My experience was interesting because I started from zero, but with the help of Splunk's professional teams, we could achieve our project. On a personal side, it helped me to gather the knowledge that brought me here at the Splunk conference.

The setup is always challenging. We had four or five people involved in the migration. We also involved a lot of key players in application migration. We had 20 to 30 people involved at some point in the migration path.

We used professional services.

We have, for sure, seen an ROI with Splunk. Our DevOps team is able to gather faster answers to their questions. Obviously, it brings value, whether it is Splunk or any other tool.

We could see the ROI in a few months. We gave time to our DevOps specialists to embrace the solution and get used to it. From there, as they made their own usage and use cases of the tool, it gave them speed to achieve what they were looking for.

I would rate Splunk Cloud Platform a seven out of ten.

We have a lot of third-party contractors that come in on our network and do the work. We use it to pretty much check what they are doing and make sure they are not doing anything that they are not supposed to be doing.

We do a lot of user interaction. We have users logging in, and we mainly look into failures and what is causing them to get locked out. We do a lot of that.

We also have Duo. We use Splunk Cloud Platform to keep an eye on who is using Duo, where they have failures, and why. We have quite a few people who are not supposed to be using Duo, and then they end up, for whatever reason, on the Duo side of the house. We use it to keep an eye on them so that we can help them get back to where they are supposed to be.

The improvement is in terms of helping those users who get locked out because we have that happen quite often. Daily, we have users getting locked out, and using Splunk makes it so much easier to help them. Rather than trying to go to the server and find those logs, we can just go to Splunk and then the dashboard for that particular user and find out exactly which machine is causing the lockout.

It helps us to easily find out which machine is causing the lockout. A lot of people know that customers can exaggerate. We can bring that back into perspective. They might say that they get locked out every day, whereas it might be once a week. We can see that. We do have a dashboard that tells us who is locked out right now. We do use that, and it helps us a lot because even before the user realizes it, we can go back and help. That helps us because they almost do not even know that it is happening. We can see it in real time, and we can fix it and unlock it. If it is something that is reoccurring, we can say, "You have been getting locked out multiple times in the same place for the last couple of hours. Go check this." We can also see why they were locked out. If somebody is putting in the wrong password, we can ignore that and unlock it. We, of course, are going to see where it is coming from. If we see some weird IP address or some weird computer that looks like it belongs to us, we will address that, but it helps us to help the user quickly. We are told what is happening as opposed to having to ask what is happening. We have definitely seen time to value. Instead of having to research, we are told it is there.

The Splunk Cloud Platform has reduced our mean time to resolve. It has easily saved 20 to 30 minutes every time someone gets locked out. We get 10 or 15 instances per day where people get locked out. It definitely saves a few hours per day.

Splunk Cloud Platform definitely frees us up to handle true problems and do true troubleshooting as opposed to handling lock-out issues. It is, of course, big for the user, but it is minute for us because it is answering a question that does not really matter to us. It matters to the user, but for us, we can just unlock their account, and we can figure out why at another time, whereas now, we can unlock their account and figure out why immediately. For example, if it was a machine that they logged into but they do not remember, or they have a cell phone that they logged into but they have not changed their password on, we can figure that out a lot quicker. That helps them quicker. It keeps us from having to go back to that user, and we can knock that out right then and there.

We have not gone into its ability to predict, identify, and solve problems in real time because we use it more after the fact. We do have an MSP, and they handle more of the security side. Their software does real-time monitoring, and they get alerts. We use the Splunk Cloud Platform to see what has already happened.

All the features are very equal for me. I do not use any one feature more than the other. They all are pretty equal to me.

It works as needed, and it does everything that we want to do. I have not come across anything that I would consider missing as such. If anything, sometimes we have dashboards that would not go into the dark mode. It is a minor issue, but it is the only thing that I wish was there. The dark mode would definitely help.

We have been using the Splunk Cloud Platform for about three years.

It has always worked when we needed it.

We are a very small shop. We only have 150 gigs a day, and we are not anywhere near that 150. However, from what I see, if there is an easy transition from 150 gigs to 300 terabytes, that is easy scalability.

We did not use any similar solution.

I was not involved in its deployment. It was already implemented.

Splunk Cloud Platform has been able to provide business resilience by empowering our staff, but currently, only two of us use it. One thing about coming to the Splunk conference is that we learn a lot. It is a lot more than what we probably can do. We also learned that for most people here, Splunk is a big part of their job. That is their main focus, whereas we have so many different things. We use Splunk; we do a little bit of networking. We do troubleshooting from swapping computers to the almost top level of moving cables.

I would rate the Splunk Cloud Platform a ten out of ten.

We use it for IT security and observability.

We did not have anything prior to this that could perform the same function. Previously, if we needed to trace a security event, we had to search across logs on multiple systems to figure it out. Since Splunk, we have got it all in one place, and we can dashboard that out and save searches.

It has reduced the time for root cause analysis. It gets us to the logs quicker, so it has reduced our mean time to resolve (MTTR). The time saved is entirely dependent on what the problem is, but it shaves a good hour or two off the initial investigation per incident.

It would improve our company's resilience if it was used effectively. It has helped the technology teams that do use it improve their business resiliency. It needs either evangelizing or being made more accessible to the front-end teams or departments that do not use it today. That is largely on us. We can do that in Splunk, but there is a never-ending list of things to do, and a part of that is building Splunk outs so that we can provide that centralized logging, and then give users access to it while maintaining the privacy of their data within our organization.

We have probably not seen any cost efficiencies. The benefit of any cloud platform such as Splunk, AWS, or Azure is that you do not have to look after it, but you pay a premium for that. For example, for VMware, you pay a premium for vCenter, vSphere, etc. You can do the exact same thing with OpenStack, but you need to hire five people to look after it versus two people for VMware. You pay for Splunk Cloud, but you run into other challenges. You do not own your data anymore because it is now stuck there, and you have to export to AWS, and then rehydrate into a different Splunk instance if you want to get access to it, or you pay through the nose for the data or retention history. It is horses for courses.

Do you want to host it yourself and save money on the OpEx but spend more on headcount and CapEx, or give it Splunk Cloud and spend more CapEx, but save money on CapEx and headcount? I prefer to have it on-prem. I prefer to go down the CapEx and headcount route because it gives me more control over my data, and it gives me more flexibility of my data. It gives me easier access to troubleshooting when something is wrong. It gives me easier access to scaling when we are seeing performance issues. I can bulk my hardware. It does not lock me into Splunk Cloud Platform. I know that Victoria promises some improvements around that with being able to manage my own applications and being able to have auto-scaling on search heads, but I will believe that when I see it, and I have not seen that yet, so I would personally prefer to put money in somebody pocket and food on their table than to give money out to a cloud provider.

I do not really like it, but being able to correlate events across platforms in a single place is valuable. I can trace an event back to its root cause. I can find the root cause instead of just looking at the symptoms across different things.

Its stability and performance can be better. Very rarely does a day go by when we do not see an error in the console, such as a health check error. Because it is cloud-hosted, we do not have access to the backend to figure it out ourselves. We are reliant on their support to figure it out, and a couple of days later, the error comes back or it is a different error. It is a never-ending cycle of support tickets. Their support is also not great.

In terms of performance, we are on the classic version of Splunk. We are not yet on Victoria or the new version, so we do not get auto-scaling. Therefore, we are limited. 90% of the time, Splunk is not doing anything. It is just reading logs, and 10% of the time is when we need to use it, but when we actually need to use it, there are five or six different teams trying to use it at the same time, and there are speed issues with search.

I have been using this solution for about eight years.

I could not interact with them very much, but I have people who do. It is not often a pretty experience. From what I understand or from the complaints that I hear, you are often told that this is not a problem or you have done something wrong, and then magically, it manages to fix itself an hour later.

Before Splunk, we used distributed instances of Elasticsearch, Logstash, Grafana, and Graphite. This was ten years ago. Splunk was in its early days. Everybody had heard of it, but it had not become apparent why people need something like Splunk, so people had been building their own little instances. A lot of that still exists today in the organization because of the Splunk pricing model, the performance issues that we have on Splunk Cloud, and the stability. People want access to their data, but they also want to own their data. They do not want it to go into the black hole that is Splunk Cloud, so they keep it on-premises. They keep it in their own systems, such as Elasticsearch or Logstash, mostly because they can maintain sovereignty over data.

When compared to not having anything, we have seen an ROI. If we were going into it today, and that today was ten years ago, I do not think I would be at this Splunk conference. I would probably be at an Elastic conference and an Open Compute conference.

The value is definitely there, but it needs more performance around it. It needs to be more responsive. The value is definitely there in terms of a centralized point of visibility, but this value is provided by Splunk, as well as all of its competitors. Splunk potentially suffers from the same problems as ServiceNow, which is, if you want to do something clever with your data, you need a Ph.D. in data sciences to figure out how it works. It is hard to put in front of end-users who do not necessarily want to do something clever with their data. They want to be able to link it to the tools that they are familiar with.

It is a touchy subject because we are locked into it. That goes back to the rehydrating data. We cannot have the retention that we want to store for legal and compliance purposes because that is seven years' worth of data for some of the indexes, so we ship them off into S3 buckets and install them there, at which point they are invisible to Splunk, so we have to rehydrate them, but we cannot rehydrate those pockets into Splunk Cloud. We have to rehydrate them into a self-hosted version of Splunk, which can take days to set up and get going. I would not call Splunk's licensing and pricing predatory, but they have made it very difficult to maintain the independence of your own data.

There are a few solutions out there that are similar to Splunk. You can get something similar with CloudWatch, BigQuery, Azure Monitor, and Azure Sentinel. In the cloud, Azure Monitor for the analytics platform and Azure Sentinel for the SIEM platform are the biggest competitors of Splunk. When you put dollars next to them, they all cost about the same at the end of the day. I probably would not trade Splunk for another cloud provider or another cloud-hosted solution.

We are heavily AWS compared to every other cloud. If that was not true and we were heavily Azure, I would probably move everything to Azure Monitor and Azure Sentinel to get that single ecosystem, but we are not going to live in that world. I also do not like AWS CloudWatch, so we are not doing that. On the cloud-hosted side of things, Splunk does not really have a competitor out there. Despite being very mature, Grafana is not as convenient as Splunk, but Splunk definitely has on-prem competition. Ten years ago, everybody was itching to get to the cloud. Everybody was pushing everything to AWS. It was like, "We have got to go to the cloud. We have got to be the first. We have got to be hybrid." Now, everyone is like, "I can do this cheaper in my own data center and have more control over it and not go offline every Friday when AWS East goes down." The competition for Splunk Cloud is with Splunk on-prem and probably Elastic on-prem, which is significantly cheaper and offers 99% of the same functionality.

In terms of Splunk's ability to predict, identify, and solve problems in real time, if this capability exists, I have not seen it.

We monitor multiple cloud environments with it. We also have the on-prem environment and a lot of SaaS providers. We are largely dependent on the people who are deploying to the cloud. They are configuring their services and their platforms to talk to Splunk. We provide Splunk as a centralized service, but it is largely up to them whether they consume it or not. Some departments are eager to get in there so they can get visibility. Some want to build their own little greenfield internally, and some have not reached the maturity of realizing why they want it.

I would rate it a six out of ten. We have frequently run into many performance problems with it. The search is slow. We cannot scale it. We cannot troubleshoot it. We cannot get access to some of the functionality that we wanted, which is changing because we are moving to the new version. We also want to be able to manage our own applications. We are just locked into this parted sandbox, and we send our data off to it, and all of a sudden, it is no longer our data because it is trapped in the Splunk cloud. If we wanna get it out, it is going to cost us money. Their support is also not great, but it does provide single-pane access to data from a whole bunch of different places.