Devops tool for AWS

I'll start by saying that I like the idea. a lot. I'm curious to see if you're already getting traction with this?

Now onto feedbacks.

I actually really like the simplicity of the webpage. 🙂 The "What" is clear. It would be great to align the bottom of the pricing elements.
Given how much volume can get out of CloudTrail at scale, as a client I'd be a bit worried of 1. my Lambda cost exploding. I know it can be negligible...until it isn't. 2. Either my Slack bill exploding or my slack history being wiped out in the free tier.
I may have missed it in the feature, but it would be useful to put some watches on terms and such instead of getting the full firehose of events. I remember a pain we had with pushing app logs to Slack was that not everyone in the team is interested in the same thing. So you could envision easy to create/delete channels or threads to allow different teams to only get messages relevant to them.
I think you should articulate use cases more clearly, i.e what job is this solving for me as a DevOps/Platform/InfoSec/etc guy. And why shouldn't I have the intern build something like it next sprint instead of subscribing to the service?

Please don't take any of this as negative, more as different ideas to take/ignore to improve the product.

Happy coding!

Say something nice to RikardH…

2
I'll start by saying that I like the idea. a lot. I'm curious to see if you're already getting traction with this?

Now onto feedbacks.
- I actually really like the simplicity of the webpage. 🙂 The "What" is clear. It would be great to align the bottom of the pricing elements.
- Given how much volume can get out of CloudTrail at scale, as a client I'd be a bit worried of 1. my Lambda cost exploding. I know it can be negligible...until it isn't. 2. Either my Slack bill exploding or my slack history being wiped out in the free tier.
- I may have missed it in the feature, but it would be useful to put some watches on terms and such instead of getting the full firehose of events. I remember a pain we had with pushing app logs to Slack was that not everyone in the team is interested in the same thing. So you could envision easy to create/delete channels or threads to allow different teams to only get messages relevant to them.
- I think you should articulate use cases more clearly, i.e what job is this solving for me as a DevOps/Platform/InfoSec/etc guy. And why shouldn't I have the intern build something like it next sprint instead of subscribing to the service?
Please don't take any of this as negative, more as different ideas to take/ignore to improve the product.

Happy coding!
ndilsou

·
4 years ago
·
1. 1
  
  Thank you for your feedback!
  
  I have ideas, of course, of Slack not being just the receiver of the "firehose" for sure and I fight the urge to build such features until the first simple (albeit dumb) version is up and running.
  
  A few concrete use cases on the landing page is a great idea, I should def do something like that!
  
  Rikard
  
  ·
  4 years ago
  ·