Mutmaßlich um auf die Wettbewerb vieler Open Source Alternativen zu reagieren, hat Mircosoft mit dem Small Business Server 2003 erstmals ein Produkt auf den Markt gebracht, das für kleine Arbeitsgruppen und Firmen (vorzugsweise im KMU Bereich) wie gemacht scheint. Mittlerweile gibt es mit dem SBS 2011 die zweite Weiterentwicklung dieser Plattform. Die Besonderheit des Small Business Server ist, dass er bis zum einer maximalen Benutzeranzahl von 75 nicht nur die klassischen Fileservices von Windows und den Active Directory Domänendienst, sondern auch Exchange, die leistungsfähige Groupware von Microsoft mitbringt. Alles in allem lässt sich inkl. Lizenz für 5 Arbeitsplätze und Basisbetriebssystem sowie notwendiger Hardware im mittleren 4-stelligen Bereich eine Plattform aufsetzen, die den Anforderungen vieler KMU vollends genügt.

Allerdings gibt es mehrere Eigenheiten, die das sonst überaus positive Bild dieser Technology trüben.

1.) Für den Windows 2003 SBS ist es nahezu unmöglich Iphones an den Exchange Server anzuschließen und so den nahtlosen Austausch von Kontakt, Kalender und Maildaten sicherzustellen. Obwohl im Internet viele Dokumente, Foren und Workarounds existieren, scheint es zu einem gewissen Anteil auch Glück zu sein ob sich Iphone mit der Infrastruktur verbinden lassen oder nicht. Wir haben bei ingesamt 4 Kunden über die Jahre versucht diese Verbindung in Betrieb zu nehmen und sind leider in 3 von 4 Fällen nicht zum gewünschten Ziel gekommen. Eine sowohl aus unserer als auch aus Sicht unserer Kunden höchst unbefriedigende Tatsache. Zudem musste als Grundvoraussetzung immer das SP2 des Exchange Servers eingespielt werden, was außer der notwendigen Komponenten für die Anbindung des Iphone kaum nützliche Vorteile mit sich brachte. aber zumindest mit einem erwähneswerten Risiko behaftet war.

2.) Mit dem Windows 2008 SBS wurden die bei der 2003er Version mitgelieferten Outlook Lizenzen eingespart und der Kunde so auf das Outlook Web Interface gezwungen. Diese Technologie ist jedoch speziell in der 2008er Version nicht annähernd so ausgereift wie der Outlook Rich Client und sorgte bei nicht wenigen Kunden für erhebliche Verstimmung

3.) Microsoft liefert zur Konfiguration des SBS einen eigenen SBS-Server Wizard mit, der es Normalverbrauchern ermöglichen soll den Server zu konfigurieren. Die Grundfunktionen des SBS lassen sich damit auch gut konfigurieren. Sollte jedoch ein erfahrener Administrator auf die Idee kommen, Rollen und Rechte mit den Windows Standard Management Consolen zu ändern, führt das mitunter zu sehr häßlichen Seiteneffekten, weil im Hintergrund von den SBS-Wizards Sicherheitpolicys geschrieben werden (über sogenannte Templates), die an keiner Stelle dokumentiert sind. Legt man also einen Nutzer über die normale AD Konfiguration an, kann es schon vorkommen, dass dieser ganz andere Defaultwerte hat. In der Regel führt das zu mehr Frust als Freude.

4.) Seit Windows 2008 Server erlaubt Microsoft auch den gleichzeitigen Betrieb eines Terminal Servers als virtuelle Maschine innerhalb eines SBS2008. Sowohl die dafür nötige Virtualisierungtechnologie Microsoft Hyper-V wie auch die Erlaubnis die Lizenz sozusagen für einen zweiten (virtuellen)=Server zu nutzen liefert Microsoft mit. An sich eine tolle Sache, lässt sich der Windows 2008 Server leider nicht ohne weiteres “headless” also ohne grafische Konsole installieren obwohl dies eines der interessantesten neuen Features ist. Bei unseren Versuchen klappte die notwendige Verbindung von einem Windows Vista / 7 Rechner auf den Virtualisierungsdienst des Servers leider auch nach dem Update auf die v2 des Hyper-V Dienstes nicht.

5.) Der Virtualisierungdienst lässt bei einem unserer Kundenserver (der mit 24 GB Hauptspeicher) versehen ist kein Assignment von mehr als 10GB Ram für die virtuelle Maschine zu. Das Problem ist darüberhinaus nicht determinstisch nachstellebar, weil sich der Dienst zwar über ungenügende Ressourcen beschwert, tatsächlich aber nur 6 GB vom Host selbst belegt sind. Von einer optimalen Ressourcenaufteilung kann also leider nicht die Rede sein

6.) Wird der Festplattenplatz auf dem Host zu klein <5% freier Speicher, schickt der Server zwar wie es wünscheswert ist dem Admin Benachrichtigungsmails, stellt aber genauso und ohne Warnmeldung den Popzustelldienst von Emails ein. Gerade in Kommunikationsintensiven Branchen ist dies ein unglücklicher Zustand.

7.) Zugegeben, der Versuch einen Windows XP-Rechner mit dem Netbios Namen “Server” einer Domäne hinzuzufügen, deren primärer Domänencontroller ein Windows 2003 SBS mit eben demselben Namen ist und dabei zu versuchen, den Namen on-the-fly zu ändern klingt auf den ersten Blick risikobehaftet.  Aber muss man wirklich davon ausgehen, dass dieser Vorgang die komplette Domänenstruktur des Servers mit folgendem lapidaren Kommentar zerlegt ?

“Der neue Rechnername “CLIENT8″ konnte nicht übernommen werden. Statt dessen wurde mit dem alten namen “SERVER” beigetreten.”

Fazit

Insgesamt, stellt Microsoft damit unseres Erachtens zwar ein, der Featureliste nach hervorragendes Produkt zur Verfügung, aber die Details seiner Anwendung und vor allem die nicht nachvollziehbaren und zum Teil noch nicht mal nachstellbaren Fehler und Einschränkungen trüben das Bild erheblich. Wann immer wir deshalb nicht explizit auf eine Windows Plattform angewiesen sind (z.B. zum Betrieb von Datev oder Sage) werden wir in Zukunft eher zu stabilen Linuxplattformen wie RedHat oder Ubuntu greifen. Fehler gibt es zwar auch unter Linux, aber beherzte Blicke in Klartext Logfiles bringen Probleme und damit häufig auch die Lösung selbiger in der Regel schneller ans Tageslicht als kryptische Fehlermeldungen a la

“Es ist der Fehler 0x80005405f aufgetreten.”

Im Open-Source Bereich ist Magento zur Zeit eine der beliebtesten eCommerce Lösungen. Wir hatten vor kurzem die Gelegenheit in einigen Projekten mit Magento zu arbeiten und sind damit in der Lage das Potential genauer einzuschätzen. Mit diesen Beitrag wollen wir ein kritischen Blick auf das Shop-System werfen und die Frage beantworten, ob und unter welchen Umständen wir diese Lösung unseren Kunden empfehlen würden und worin potentielle Probleme begründet liegen.

1) Betrachtung aus Sicht des Entwicklers

Auf den ersten Blick sieht Magento sehr vielversprechend aus. MVC-Design-Pattern, Events, viele Module, Konzepte mit Collection usw.,  sind Eigenschaften die einem erfahrener Entwickler und Softwarearchitekten den Eindruck aufzwingen, dass es sich bei Magento um moderne, gut konzipierte Software handelt.

Nach kurzer Zeit merkt man jedoch, dass nicht alles Gold ist, was glänzt. Funktionen tun andere Dinge als die Dokumentation vorgibt,  soweit überhaupt eine Dokumentation vorhanden ist. Collections verhalten sich dann leider auch anders als erwartet. Wichtige Funktionalität ist an Orten im Code untergebracht, an denen man sie nicht ansatzweise suchen würde.

Insbesondere bei der Verbindung zwischen Application und Datenbanklayer schlägt die Vielzahl von Abstraktionsschichten voll durch und führt zu einer Flut an SQL-Statements. Diese werden dann auf Entity-Tabelle, Flat-Tabellen, EAV-Tabellen und Index-Tabellen ausgeführt.

Insgesamt stellt dies zwar aus Sicht der Datenhaltungstheorie ggf. eine optimale Lösung dar, allerdings führt Sie zu maximaler Komplexität und daher äußerst schlechter Performance.

2) Community vs. Commercial Licence

Magento hat eine Dual-Licencing Strategie. Die Community Edition steht unter OSL. Daneben gibt es eine kommerzielle Enterprise Lizenz. Die Enterprise Version hat einige zusätzliche Features. Die Interessantesten unter Ihnen sind die Einbindung von Apache SOLR für die Suche und der Full-Page-Cache. Zumindest offiziell gibt es auch einen Support.

In der Praxis liefert dieser jedoch kaum einen Vorteil. Tickets werden ewig oder gar nicht bearbeitet. Da es sich bei einen Shopsystem immer um eine stark anwendungsbezogen angepasste Anwendung handelt, ist man bei der Anpassung ohnehin meist sich allein gestellt, selbst wenn Probleme in den Core Komponenten auftreten.

Full-Page-Cache ist zwar eine nette Sache, aber selbst mit selbigem, ist Magento so langsam, dass das Nutzererlebnis nicht überzeugen kann. Für eine eCommerce Anwendung ist das in unseren Augen eine maximal ungünstige Situation. Entweder man lebt damit, das die Performance schlecht ist, dann bleibt bestenfalls (ein Teil) der Kundschaft aus. Oder man investiert sehr viel Zeit und Geld in Performancetuning.

3) Was wirklich nervt

Ein paar Bugs muss man jeder Software verzeihen. Die entscheidende Frage ist aber wie schwer die Bugs wiegen bzw. welcher Aufwand zum Fixen durch Updates oder Workarounds entsteht. Magento ist hier ein sehr negatives Beispiel. Es verlangt von einem Entwickler nicht nur eine hohe Frustrationsgrenze ab, sondern auch von Kunden, da einige Fehler erst im produktiven Betrieb (also unter Volllast) zu Tage treten. Die ist für ein Kunden mit ausführlicher und gut organisierte Test- und Stagingphasen besonders ärgerlich. Insgesamt hat Magento unseres Erachtens noch zu viele Fehler, insbesondere wenn es im Enterprise Bereich eingesetzt werden soll.

4) Fazit

Unser Fazit ist, das die Qualität von Magento ingesamt nicht stimmig ist. Die Enterprise Edition ist ihr Geld unseres Erachtens nicht wert, da ein funktionierender Support quasie nicht existiert. Die Performance ist nicht ein Problem, sondern das Problem, womit wir praktisch jedem Kunden abraten würden auf Magento zu bauen.

Für kleiner und mittlere Projekte ist Magento einfach zu viel Code und viel zu komplex (Design Paradigma). Man ist daher mit einem kleineren performanteren Shop wie Presta vermutlich besser bedient. Für größere Projekte im Enterprisebereich ist Magento vor allem wegen seiner Performanceprobleme nicht geeignet. Wichtige Funktionen müssen zum Teil per Java oder JavaScript nachgerüstet werden.

Der Designoverhead (Abstraktionsschicht) sorgt dafür dass ein Export von Produkten aus Magento gut 50 Stunden dauern. Ein SQL-Statement an dieser Stelle  wäre sicher deutlich performanter. Wir sind der Auffassung, dass für vergleichbare Investitionssummen eine, auf eigenen funktionalen Anforderungen basierende Anwendung mit einem PHP-Framework der Wahl entwickelt werden kann. Dann kann man die Funktionalität abbilden, die wirklich gebraucht wird und eine Performance erreichen, die im Falle Magentos nur mit viel bis sehr viel Tuning zu erreichen wäre.

Unseres Erachtens liegt die wesentliche Ursache des Problems darin, dass es sich bei Magento um ein künstliches Open Source Projekt handelt, dass weniger den Nutzen einer breiten Community von Anwendern (die allerdings sicher existieren würde) als mehr die strategischen Ziele des Herstellers und dessen Kapitalgebern im Auge hat. Die Tatsache, dass Ebay die Mehrheit der Anteile an  Magento Inc. übernommen hat verstärkt diesen Eindruck weiter