Image manipulation is the one thing I also run as a micro service whenever needed. I just set up imagor once and never need to manage that in the installation/images of all other apps. No extra memory for shelling out to libvips or imagemagick needed.
The PDF use case also sounds very promising low hanging fruit
That was actually excacly our angle of attack: see the routes, modules or jobs that were putting the most pressure on the servers.
Then copy the entire app over to separate servers, connected to the same db cluster. Have an app router direct everything except, say /reports/ to the old servers, and /reports/ itself to the copies on new servers.
Did the old servers reduce significant in load? Rip out the part there. Better? Now rewrite, cleanup, isolate or extract the, e.g. /reports/ part on the servers. Better?
Then, finally, disconnect the service from the shared DB (microservices sharing a DB is the worst idea ever.) and have it communicate either via a message bus, via REST calls or not communicate at all.
The PDF use case also sounds very promising low hanging fruit