Gremlin Free – Run chaos experiments to prevent outages • Hacker News Board

Re: Gremlin Free – Run chaos experiments to prevent outages

#51

Post by TheSpiceIsLife » Thu, Feb 28, 2019, 6:27 AM UTC

TheAceOfHearts wrote: post #50

TheSpiceIsLife wrote: post #42

Earlier quoted context omitted.

I can’t speak for this vendor in particular, but one common reason for pricing like this is the vendor doesn’t want to deal with smaller customers as they often have the highest support requirements.

Pretty much. An enterprise customer won't bat an eye at $12K/year, and I imagine it'd pay for itself pretty quickly. I can definitely relate with GP, though. It feels frustrating to learn about an interesting product only to find that it's priced way outside of your budget. At least Gremlin has a public sticker price. Sometimes enterprise services just skip that completely and require you to setup a call with someone…

> which usually means the service is outside of your budget.

I wonder if this is true though.

Maybe it puts off people who otherwise might be able to have a product tailored to their budget???

Re: Gremlin Free – Run chaos experiments to prevent outages

#52

Post by lklig » Thu, Feb 28, 2019, 5:38 PM UTC

goldenkey wrote: post #44

Failure as a service doesn't make all that much sense considering that a many failure scenarios would make the target host inaccessible to Gremlin. How does Gremlin handle this?

Good question! All of the network attacks have a whitelisting capability, to keep the host accessible. This isn't an issue with state attacks, as the client will come back online once the host reboots. And with resource attacks the client typically remains active, if your application is handling starved resources well.

Re: Gremlin Free – Run chaos experiments to prevent outages

#53

Post by dkersten » Thu, Feb 28, 2019, 6:31 PM UTC

TheSpiceIsLife wrote: post #42

dkersten wrote: post #5

Earlier quoted context omitted.

I like the look of this and love that you have released a free version. I am a little dismayed, though, that the two options are $0 and $1000/m (paid annually) with nothing in between. The free version seems great to get started, but I'd really like a lot more of the attacks that the paid version has, but $12,000 is much, much too high a price for a startup or personal project. That's quite a jump in cost.

I can’t speak for this vendor in particular, but one common reason for pricing like this is the vendor doesn’t want to deal with smaller customers as they often have the highest support requirements.

Sure, but then why tease us with a cut-down free tier?

Re: Gremlin Free – Run chaos experiments to prevent outages

#54

Post by dkersten » Thu, Feb 28, 2019, 6:33 PM UTC

TheSpiceIsLife wrote: post #51

TheAceOfHearts wrote: post #50

Earlier quoted context omitted.

Pretty much. An enterprise customer won't bat an eye at $12K/year, and I imagine it'd pay for itself pretty quickly. I can definitely relate with GP, though. It feels frustrating to learn about an interesting product only to find that it's priced way outside of your budget. At least Gremlin has a public sticker price. Sometimes enterprise services just skip that completely and require you to setup a call with someone…

> which usually means the service is outside of your budget. I wonder if this is true though. Maybe it puts off people who otherwise might be able to have a product tailored to their budget???

Its possible. I know a guy who isn't put off buy "call us" pricing notices and he seems to get good deals, so its certainly possible. Many of us will never find out though, because "call us" means "close tab". Even if I really want their product and am willing to pay a lot for it, my time is too precious to me to waste on calls.

Re: Gremlin Free – Run chaos experiments to prevent outages

#55

Post by dkersten » Thu, Feb 28, 2019, 6:40 PM UTC

dbaggerman wrote: post #38

Negitivefrags wrote: post #35

Earlier quoted context omitted.

It sounds like you are saying "The in-flight requests fail" to me. I really don't like the idea of saying that it's simply okay to give random users a bad user experience like that when you are actually killing servers yourself all the time.

It's a different approach to managing risk -- minimizing impact of failure rather than minimizing the likelihood of failure. It's nice to know that you can kill a process and the only impact is that in-flight requests fail, rather than having a more significant outage if a process crashes and the failover doesn't work, or the process doesn't automatically restart, etc. If you accept that requests will fail you can bu…

Another thing that's not often caught by "normal" testing but that chaos engineering can capture is when multiple things fail together in random ways. It can be surprising how otherwise robust services can fail badly when multiple things go wrong at once.