esc.media-converter

Entstanden ist esc.media-converter während des Aufbaus von Themis: Eine der Anforderungen war die Publikation von Videos, die aber oft in für das Web ungeeigneten Formaten vorlagen (avi, wmv, mov, mpeg, etc).

Nach ein wenig Recherche war klar, dass es keine fixfertige Bibliothek oder Software zu kaufen gibt die man nutzen könnte. Ich entdeckte aber diverse Dienste, die Video Encoding in der Cloud offerierten, einer davon war die Firma Encoding.com. Diese bot, neben dem Versprechen mit x verschiedenen Formaten umgehen zu können, auch eine API für die Übermittelung von Konvertierung-Tasks aus der eigenen Applikation an (die Video-Dateien werden via FTP abgeholt und geliefert, im XML wird der Pfad dazu angegeben).

Im Hinblick darauf dass zukünftig wohl auch andere Kunden Videos im Web veröffentlichen wollen, wurde, anstatt die Encoding.com API direkt ins Themis zu integrieren, ein Escapenet eigener Service erstellt. Dieser soll Web Applikationen von Escapenet und deren Kunden eine einfache Möglichkeit bieten, Medien verarbeiten bzw konvertieren zu lassen, ohne dass jedesmal eine zeitaufwendige Implementation von Drittanbieter-APIs nötig ist. Einfachheitshalber wurde die Kommunikation / API hier ebenfalls XML basiert umgesetzt.
Neben Videos kam dann schnell auch die Möglichkeit der Verarbeitung von Bildern (Erstellung von Bild-Kopien in Auflösung xyz) und den Vorschaubildern von PDF-Dateien (Erstellung von Bild-Dateien bestimmter PDF Seiten) dazu.
2015 kam im Rahmen eines Kundenprojekts die Option dazu, CAD Pläne (DWG) zu konvertieren (in DXF, PDF und PNG); dies wurde mit Hilfe einer .Net Bibliothek (cadlib) umgesetzt.

Über eine Weboberfläche lässt sich jederzeit ein Blick auf die aktuellen und vergangenen Tasks werfen. Auch lassen sich manuell Tasks erstellen falls man z.B. ein einzelnes Video konvertieren muss.

Anfangs wurden die Tasks noch von derselben Webinstanz ausgeführt, die auch Tasks der Web Applikationen entgegennimmt. Dies führte dazu, dass wenn die Instanz damit beschäftigt war, ein paar grosse Bilder zu verkleinern, Anfragen in ein Timeout liefen.
Deshalb wurde in einer zweiten Phase die ganze Struktur gesplittet und auf verschiedene Web-Instanzen verteilt: Neu gibt es einen Task-Manager der sich um die Verteilung der Aufgaben kümmerte. Die Tasks werden von dedizierten Workers ausgeführt, jeder ist eine eigene Webinstanz und damit berechtigt, einen CPU-Thread für sich zu beanspruchen. Die Anfragen der Web-Applikation übernimmt eine Kommunikationsinstanz.
Es ist mit dieser Strukturierung auch ein Leichtes noch mehr Workers aufzusetzen und so die Skalierung weiter zu erhöhen: Aktuell laufen drei Workers gleichzeitig, ein vierter ist in Reserve und inaktiv.