The journey to Thumbor, part 1: rationale
By Gilles Dubuc, Engineering Manager, Wikimedia Performance Team
We are currently in the final stages of deploying Thumbor to Wikimedia production, where it will generate media thumbnails for all our public wikis. Up until now, MediaWiki was responsible for generating thumbnails.
Security
The biggest reason to change the status quo is security. Since MediaWiki is quite monolithic, deployments of MediaWiki on our server fleet responsible for generating thumbnails aren’t as isolated as they could be from the rest of our infrastructure.
Media formats being a frequent security breach vector, it has always been an objective of ours to isolate thumbnailing more than we currently can with MediaWiki. We run our command-line tools responsible for media conversion inside firejail, but we could do more to fence off thumbnailing from the rest of what we do.
One possibility would have been to rewrite the MediaWiki code responsible for thumbnailing, turning it into a series of PHP libraries, that could then be run without MediaWiki, to perform the thumbnailing work we are currently doing – while untangling the code enough that the thumbnailing servers can be more isolated.
However such a rewrite would be very expensive and when we can afford to, we prefer to use ready-made open source solutions with a community of their own, rather than writing new tools. It seemed to us that media thumbnailing was far from being a MediaWiki-specific problem and there ought to be open source solutions tackling that issue. We undertook a review of the open source landscape for this problem domain and Thumbor emerged as the clear leader in that area.
Maintenance
The MediaWiki code responsible for thumbnailing currently doesn’t have any team ownership at the Wikimedia Foundation. It’s maintained by volunteers (including some WMF staff acting in a volunteer capacity). However, the amount of contributors is very low and technical debt is accumulating.
Thumbor, on the other hand, is a very active open-source project with many contributors. A large company, Globo, where this project originated, dedicates significant resources to it.
In the open source world, joining forces with others pays off, and Thumbor is the perfect example of this. Like other large websites leveraging Thumbor, we’ve contributed a number of upstream changes.
Maintenance of Wikimedia-specific Thumbor plugins remains, but those represent only a small portion of the code, the lion’s share of the functionality being provided by Thumbor.
Service architecture
For operational purposes, running parts of the wiki workflow as isolated services can be beneficial. It enables us to set up the best fencing possible for security purposes, where Thumbor only has access to what it needs. This limits the amount of damage possible in case of a security vulnerability propagated through media files.
From monitoring to resource usage control and upstream security updates, running our media thumbnailing as a service has significant operational upsides.
New features
3rd-party open source projects might have features that would have been low priority on our list to implement, or considered too costly to build. Thumbor sports a number of features that MediaWiki currently doesn’t have, which might open exciting possibilities in the future, such as feature detection and advanced filters.
At this time, however, we’re only aiming to deploy Thumbor to Wikimedia production as a drop-in replacement for MediaWiki thumbnailing, targeting feature parity with the status quo.
Performance
Where does performance fit in all this? For one, Thumbor’s clean extension architecture means that the Wikimedia-specific code footprint is small, making improvements to our thumbnailing pipeline a lot easier. Running thumbnailing as a service means that it should be more practical to test alternative thumbnailing software and parameters.
Rendering thumbnails as WebP to user agents that support it is a built-in feature of Thumbor and the most likely first performance project we’ll leverage Thumbor for, once Thumbor has proven to handle our production load correctly for some time. This alone should save a significant amount of bandwidth for users whose user agents support WebP. This is the sort of high-impact performance change to our images that Thumbor will make a lot easier to achieve.
Conclusion
Those many factors contributed to us betting on Thumbor. Soon it will be put to the test of Wikimedia production where not only the scale of our traffic but also the huge diversity of media files we host make thumbnailing a challenge.
In Part 2: Thumbnailing architecture, I’ll describe the architecture of our production thumbnailing pipeline in detail and where Thumbor fits into it.
About this post
This post was originally published on our Phame blog.
Featured image credit: Abbotsford House Study Room by Michael D Beckwith (CC0 1.0).
