I agree. Offloading this type of work to a third party who does it really well is a smart move. Why manage additional code when it's not even core to what you do?
In this case, it was perhaps cheaper for them to do in-house, and it's not rocket science? They wrote a bleeding edge library for it - sounds like they have the expertise just fine. Minimizing external dependencies can be a big deal if you have the developers to manage it.
Also, it is totally core to what they do. Images are a huge part of the Discord UX.
At 150m images per day, not counting bandwidth, imgix would cost ~135k/month. Running 12 n1-standard-16 instances (peak load according to the article) is ~$5k/month. It's not hard to see why we wrote it in house when you consider that cost.
Ok, so why a new library and associated dev time when thumbor and other libraries already exist, especially if you're willing to spend 5k/month on instances just for this?
That was pretty clear in the post - they didn't find a Golang lib that could compete with their pillow-simd on resizing, which was the main performance bottleneck.
Why was a Go version needed if performance was paramount? There are libraries already that can handle this performance just fine.
If they're going to spend 60k/year on instances, the dev time definitely wasn't worth it for this. They just wanted to use that language because this is a NIH situation, not really an engineering priority.
I'm not saying that images are not core to what they do (I use Discord a lot) but processing them is almost certainly not. Dev time is expensive enough already so spending time building and maintaining a library could end up being a waste.
Also, it is totally core to what they do. Images are a huge part of the Discord UX.