Read on Twitter
I spent $20 to put up a Stripe coupon slackbot on @StandardLibrary. A couple months ago I tried to update it to a newer version of the Stripe API and bump some long-overdue deps, and completely broke everything.
I timeboxed it at eight hours. Eight hours later I still didn& #39;t have anything working. The thing that& #39;s really frustrating here is that building a slack bot isn& #39;t really all that hard; I could have it up on ~any PaaS service in probably an hour.
About halfway through, I decided, "okay, this old code just doesn& #39;t want to be upgraded." I scrapped everything and started from scratch. The stdlib "autocode" bits were simply unhelpful. I got exactly nothing working.
There& #39;s two lessons here:
1. If your service is a platform, deviating too far from the norm makes supporting your infra a burden. In this case, too much of a burden.
2. If it ain& #39;t broke, don& #39;t fix it.
1. If your service is a platform, deviating too far from the norm makes supporting your infra a burden. In this case, too much of a burden.
2. If it ain& #39;t broke, don& #39;t fix it.
The first lesson is mostly for the Stdlib folks. I& #39;m really not sure who the audience for their service is, anymore. I pegged it originally as a cute FaaS offering for little projects. It did that well. Now, it feels like they dug in on the wrong problems.
Having lots of features around deployment/versioning/etc. feels very wrong—if you need that, your& #39;e on GCloud or AWS. And those features come at the expense of simplicity...which was the whole draw of the service to begin with. I need the Heroku of FaaS, not the K8s of FaaS.
