I work with both Splunk and Sentinel and would consider myself vendor agnostic (worked with LogRythm, ArcSight and Elastic Stack too). There are a few comments I would like to make. 1. I agree Sentinel is very easy to initially set up vs Splunk / Splunk Cloud. Especially Microsoft and large vendor sources (Cisco, Fortinet, etc etc) 2. In addition to an ingest licence Splunk provide a compute based licence too. I would argue this is much easier to budget for vs ingest cost (even with Committment Tiers). I've worked with plenty of organisations (Universities for example) whose throughput massively changes from month to month 3. I would say Splunk is much more mature for non-Microsoft integrations - just look at the number of TAs available on Splunkbase. With Sentinel, you may need a developer (not a typical security engineer) to develop Function Apps to ingest into Custom Tables. 4. Skills. I would argue that Splunk, having been around 20 years, with a robust training offer - skills are much more common. Sentinel is new, and there isn't yet a specific training programme for this (Splunk Ninja Training is good though!) 5. Sentinel scheduled rules can only look back 14 days. 6. Mention of ADX for archiving. Actually Sentinel now has the very good Archive Tier. Splunk very similar (DDAA and DDSS). 7. Developing integrations for sources not yet available in Splunkbase (a rare thing) is super easy using Splunk's Add-on builder. I find with Sentinel you will need to employ someone comfortable with developing Python, Poweshell etc for developing Function Apps. These have to be maintained. Growing list of course open source on GitHub, but catching up. 8. Log source monitoring. Sentinel has some work to do to catch up with Splunk's "TrackMe" app which uses ML to detect outliers, throughput etc. 9. Licence. Sentinel is kinda similar to Splunk ES in the licence model. Sentinel (Splunk ES) is charged on the ingest volume on top of the ingest +storage cost of the underlying Log Analytics Workspace (Splunk Enterprise/Cloud) 10. Learning Microsoft KQL is required, much in the same way as the need to learn Splunk SPL. I like both, and coming from an Oracle background I kind of prefer the KQL language which is more similar and query optimisation is performed transparently. That said Splunk accelerated data is much much quicker. I also like Splunk's "schema on the fly" way of doing things. 11. A Splunk Deployment Server (or supported Ansible, Puppet, Chef, SCCM, ...) isn't mandatory, but useful for configuration of a large number of agents (if only collecting API sources, not needed for example). This is similar to Sentinel's data collection rules (DCR) now available with the AMA agent. Until AMA it hasn't been easily possible to fine tune what is collected (thinking the 4 built-in filters for Windows Security Event collection).
Disclaimer - I am a Splunk Account Manager so keep that in mind while reading my comments. I find this comparision to be extremely misleading. You compare Sentinel to a Splunk BYOL (bring your own license)) Cloud deployment. To put this in Microsoft terms you are comparing O365 to Exhange running in Azure. Not a fair comparison. I would recommend a redo on this video comparing Sentinel to Splunk Cloud with Mission Control which is a more comparable deployment model. This is not an apples to apples comparision, it is more like an Apples to Walnuts......
