Genuinely surprised anybody would acquire Splunk in 2023. Whenever you hear about Splunk from security engineers, they're actively trying to get off it (edit: yes, primarily because of cost). Better, next-gen SIEMs are either here or around the corner.
Splunk is a great product with horrible sales and business team.
The reason why them _trying_ to get off it is because they have a bunch of stuff that is easy and works in splunk, but don't want to pay the exorbitant licensing, or pay even more to increase their use.
But getting off a good product is hard, and they will continue to use it and even pay.
The kind of thing Cisco, Oracle, and IBM love are companies with very expensive products in which no development needs to happen and customers cannot move away easily.
I was in one of these meetings with like 20 engineers on how amazing this thing was. We knew that because we already used it it quite extensively. The very extremely hyper sales rep kept ducking out of the meeting every 5 mins. I recognized it for what it was. He was ducking out to do bumps of coke so he could be more pumped to sell us more stuff.
I was at a shop that got heavily integrated into Splunk for security use cases and then entered a split brain mode of 'well if you need observability we already have Splunk' but also 'hey stop doing so much observability, this thing is expensive!'.
So for 5 years time we used it for observability, we were only half-integrated and also trying to get off of it. Great stuff.
Worked on a piece of software which suffered from years of this split brain. It had some logging and some metrics, but the team was told to be economical about observability. This resulted in the software having many blind spots which led to production issues that had to be manually reproduced. When I become responsible for the software I personally overhauled the logging and the team had to work together to rebuild the metrics functionality.
this is an area that gets very political with architects, managers and other non-coders having too much of a say
a lot of paralysis on the app dev side as the status quo is easier than fighting for a sensible outcome
its also something that yes, benefits stakeholders... but only on a 2nd/3rd order effect of outage avoidance & remediation.. so theres not a huge reward for doing it really really well in many shops
I haven't heard a single person trying to get off of it because "there are better SIEMs" - they're universally looking at other options because of the price.
Cisco has the luxury of bundle and save that Splunk does not.
I can see them shipping a really cool-looking whitepaper detailing FTD, Amp, and Splunk... but actually operating it will feel similar to driving a 20 yr old salt state jeep wrangler on the autobahn.
Oh god those firepowers we bought were so bad. The controller webpage needed to control our pair needed something like 32GB of ram just to load.
Using fortigates now, far happier with them.
But it's not just the firewall level, they were so bad it made us reevaluate our core switches and I don't think we've bought a cisco switch for at least 2 years.
I used Splunk at a previous job and that’s one of my few/only complaints with it. Great tool but extremely expensive for what you get. Datadog is the same way as well as Pagerduty. There’s not enough competition in these spaces
That's super true of PagerDuty. It's a pretty good product and cheap when you only have a few people on it. However, the jump from the basic license to the next tier is HUGE and any add-ons you might need (ie. webhook triggers) bump the price up even more. Just having a simple monitoring solution with >10 people could cost you $100's a month.
That said, every other product in this space is crap. I'm not sure why though. This seems like a pretty good market for disruption. Maybe there is some hidden "problem" that I don't know about.
PagerDuty is extremely expensive and I decided to disrupt the market a little bit by creating All Quiet: You might want to check it out: https://allquiet.app
My take on xmatters is that it gives you some building blocks to build a decent paging system, and has a fair amount of flexibility, but many things that work out of the box, or with a little bit of configuration in PagerDuty require a non-trivial amount of work in xmatters to set up. And you will likely run into limitations.
Why is pagerduty hard to switch off of? It has all kinds of useless and expensive bells and whistles, while the core functionality is a commodity that several companies offer.
We moved vendors a few time and it wasn’t that painful.
What happens when Twilio is down?
Same questions for your email, sms and server. Part of the difficulty is guaranteed uptime and PagerDuty is rock solid in that regards.
Hmm, are you referring to their Observability product or SIEM capabilities? There's a wild amount of competition in the Observability side of things, but SIEM not so much.
I'd love to know what the security engineers you are talking to recommend because Splunk ES/SOAR are top notch products - even with the cost (which is insane).
Which ones do you recommend? Every one I have tried hasn't really given me the same flexibility as Splunk, most seem to miss the core part of what makes Splunk cool. Though I'd definitely like to see Splunk improve their design.
Microsoft is doing a surprisingly good job with their Sentinel SIEM. The sweetener is they give you free ingestion on most of your Office 365/Azure logs which can add up if you’re shipping out to another platform.
Makes it attractive for enterprises already on their platform and they throw in discounts for E5 license tier customers as well (gotta keep pushing the “give us everything or pay way more for single feature licenses”).
The thing that will totally replace splunk (and elastic and snowflake and likely several other whole ecosystems) is some random thing pouring data into clickhouse.
I am nervous about how clickhouse is going to monetize, whenever they decide to turn on the revenue spigot.
I hate to shill in this thread, but that's exactly what we built at runreveal, so I completely agree! We saw the power of clickhouse when we were at segment and cloudflare, so built a company around it.
And since clickhouse is open source, we hope that people will stop giving their security data to vendors who then charge you rent for it. I think the future is writing this data to clickhouse, but also our customer's clickhouses
I used to love Graylog, but I was evaluated it for use with AWS and a) it's AWS bits seem limited and b) I found a bunch of deadlinks from their github to their site. If they can't keep their docs updated, it doesn't give me warm fuzzies about their product.
Hey, founder of Tenzir [1] here — We are building an open-core pipeline-first engine that can massively reduce Splunk costs. Even though we go to market "mid stream" we have a few users that use us as light-weight SIEM (or more accurately, just plain log management).
We are still in early access but you can browse through our docs or swing by our Discord.
If you're looking for something that can handle unstructured data and has a similar query syntax to Splunk then Gravwell (https://www.gravwell.io) might be a fit.
Sounds exactly like the kind of Enterprise software Cisco wants.... At that pricepoint they don't really care what the security engineers want, they sell to higher level folks.
They want so hard to be a software company, and they already have experience with highly inflated priced products.
Their real target is probably trying to offer this built in to meraki like products as a one stop shop. I could see them finally burning their monitoring product in a fire and replacing it with splunk and grafana then selling it as an all cloud solution. At least the intent, we know Cisco's track record for integrating acquisitions.
Avoid Devo, querying across data sets with their system was hot garbage in comparison to both splunk and elastic. Then when you try and break up with them it becomes a whole thing.
Avoid Exabeam. Their UEBA product is riddled with problems, and they are not concerned that it does not display timestamps for when the event occurred- they display timestamps for event ingestion which can sometimes be hours off.
They also seem to outsource much of the development, maintenance and support and appear to have high turnover.
Having worked at a company with a million-lines-plus of Python monolith, gradual typing annotations made all the difference. Why do you need it enforced at runtime? It's static types!
They said "by the runtime", perhaps they mean that the python interpreter should throw errors at compilation time, since its not a classic compiled language.
> They said "by the runtime", perhaps they mean that the python interpreter should throw errors at compilation time, since its not a classic compiled language.
Why waste time doing static analysis each time you run the code? If you don't change the code, its not going to change.
Drew Houston needs to step down. The company has been aimless for a decade. The 'collaborative workspace' was an obviously bad idea that they sunk years of company-wide resources on (ask me how I know!)
The legacy framework was Pylons, which eventually evolved into Pyramid.
The tldr is there were hundreds of unowned endpoints that, yes, were allowed to fester. They eventually got ownership on all endpoints, so you had somebody to exert pressure on to make things happen.
Some projects need performant regexes, and some honestly just don't. I agree that keeping the base regex library linear is admirable, but it's be nice if they offered a well-marked thing like regex.slow_and_perl_like in the stdlib
This would contravene the training-wheels nature of Go.
Also, Perl-style (ir-)regular expressions, despite their popularity, are not a worthwhile abstraction IMO and thus should not be enshrined in the standard library of programming languages, even if you want them in your library eco-system for end-user facing API compatibility.
