A pipeline approval tool (internal at Amazon) that counts metrics.
I was a fairly fresh college-hire SDE1 at Amazon. And I was annoyed, because I'm lazy. Every time I was oncall, I had to manage the deployment pipeline for my teams software- the UI for the tool used by Pickers inside Amazon Warehouses. On Monday, deploy the latest changes to the China stack (small). On Tuesday, check if anything bad happened, and then deploy to the Japan stack (small-ish). On Wednesday, Europe (big). Thursday, North America (biggest). Repeat each week.
And I thought "why am I doing this? There are APIs for all of this stuff!". So I made an automated workflow that hooked into the pipeline system. You gave a metric to look for, a count of how many times the thing should have happened, and an alarm to monitor. If everything looks good, it approves. I hooked it up for my pipeline, and then it usually finished the entire weekly push before Tuesday afternoon. I made it in about 2 weekends on my own time.
And I left it open for anyone in the company to configure for their own pipelines. A few weeks later I was checking if it was still operating normally and realized there were something like 50 teams using it. Then 100. Then a lot more.
The last I heard, it's considered a best practice for all teams within the company to use it on their pipelines. Before I left in 2021, it was running something like 10,000 approval workflows per day.
I named it after the BBQ/grilling meat thermometer in my kitchen drawer- "RediFork". Given the overlap of "people who read HN" and "devs who worked at Amazon", I probably saved someone reading this an aggregate hour or two of work.
Holy shit. Forget counting the hours (which are easily into the tens, if not hundreds) you saved me and my teams - more importantly, RediFork was a great "on-ramp" for easily introducing observability in existing services without instrumenting anything new, and a great way to demonstrate the power of automation to newbies.
From one "engineer whose irritation at inefficiency spawned a whole tool" to another (I got sick of staying up overnight to run load tests, so wrote myself an automation and monitoring tool - which got picked up, spun off to its own team, and now is used by >300 teams) - thank you!
I was a fairly fresh college-hire SDE1 at Amazon. And I was annoyed, because I'm lazy. Every time I was oncall, I had to manage the deployment pipeline for my teams software- the UI for the tool used by Pickers inside Amazon Warehouses. On Monday, deploy the latest changes to the China stack (small). On Tuesday, check if anything bad happened, and then deploy to the Japan stack (small-ish). On Wednesday, Europe (big). Thursday, North America (biggest). Repeat each week.
And I thought "why am I doing this? There are APIs for all of this stuff!". So I made an automated workflow that hooked into the pipeline system. You gave a metric to look for, a count of how many times the thing should have happened, and an alarm to monitor. If everything looks good, it approves. I hooked it up for my pipeline, and then it usually finished the entire weekly push before Tuesday afternoon. I made it in about 2 weekends on my own time.
And I left it open for anyone in the company to configure for their own pipelines. A few weeks later I was checking if it was still operating normally and realized there were something like 50 teams using it. Then 100. Then a lot more.
The last I heard, it's considered a best practice for all teams within the company to use it on their pipelines. Before I left in 2021, it was running something like 10,000 approval workflows per day.
I named it after the BBQ/grilling meat thermometer in my kitchen drawer- "RediFork". Given the overlap of "people who read HN" and "devs who worked at Amazon", I probably saved someone reading this an aggregate hour or two of work.