The People Who Will Thrive in the AI Age 24 days ago
HN user
cplan
7 karma
Posts2
Comments5
When a team is too big 1 year ago
The solution arrived on here sounds a lot like the original meaning of the term "devops", and Amazon/AWS' concept of a T-shaped engineer - a generalist with deep knowledge in one area (or a least, AWS is where I personally got acquainted with these terms).
Digital Subscriber Line
I'd say, don't disable the tips that show at startup and try to incorporate them into your workflow. Maybe make some notes of the ones that seem most useful and try to refer back to them, before long you'll find your fingers remember the shortcuts.
I recently had a need for a slack bot that could dynamically select which user to notify each week based on a schedule. /remind would have been perfect for this if it let me do some computation to figure out who to @ in its notification message, so I decided to build that.
The bot currently has 2 slash commands, /sh [`command`] runs the command immediately and returns the output to you, and /notify [@user or #channel] [`command`] [cron expression] will run the command on the cron schedule and notify the user or channel of the output of that command.
At the moment it's running on a single t3.small EC2 instance with a t3.micro RDS database. Cron triggers are stored in the DB, which would allow me to add more worker nodes to distribute the load in future, if there is enough demand.
Each command runs as a non-root user in its own container under docker, on top of Google's gVisor kernel (https://github.com/google/gvisor). I've also limited the containers in their resource usage and mounted a read-only root FS (there's also a writeable tmpfs mounted at /data). Each command can run for a maximum of 5 seconds before it is automatically killed.
I'd love to hear your thoughts!