share

Spryker – eine erste Einschätzung

Wie auf Twitter zu lesen war, habe ich mich heute auf den Weg nach Berlin gemacht, um mir in den Räumen von Project A den aktuellen Stand von Spryker zeigen zu lassen.

Zum Überblick: Spryker ist der Name einer E-Commerce Software-Lösung, mit der man “Yves&Zed”, das Shopframework von Project A Ventures, kaufen kann. Auf Basis dieses Systems wurden bereits einige Startups des Unternehmens umgesetzt, so zum Beispiel Tirendo.

Zur Technik

Das System ist, wie schon auf dem Blog vorgestellt, in drei Bestandteile aufgesplittet:

Yves, das Frontend

basiert auf dem Microframework Silex aus dem Hause SenioLabs (den Machern von Symfony) und ist ausschließlich für die rasante Auslieferung der Seite zuständig. Als Tempalting kommt hier passenderweise die Twig-Templatingengine zum Einsatz, ebenfalls von SensioLabs. Schnell wird das ganze, weil hier keinerlei Anbindung und Logik implementiert sind. Die Daten kommen ausschließlich aus einem KeyValue-Store (default: Redis) sowie, wenig überschend, Elasticsearch. Zusätzlich werden die Sessions in einem zentralen Speicher vorgehalten, ebenfalls gerne Redis.

Dies unterstützt den Ansatz, das System äußerst skalierbar zu halten. Project A bevorzugt Rackspace als Hoster und hat entspechend auch die Technologien gewählt.

Zed für die Logik

Geht es um Logik, also das Absetzen einer Bestellung, erfolgt dies über die Backend-Komponente Zed. Entgegen der im Blog angelegten Grafik, basiert auch Zed inzwischen auf Silex, beziehungsweise soll dies das ZendFramework ablösen, doch dazu gleich noch mehr.
Zed spricht mit der MySQL-Datenbank und enthält sämtliche Berechnungen der Anwendung. Der Austausch zwischen den beiden Komponenten erfolgt mittels einer einfachen JSON-API. Zudem ist Zed dafür zuständig, die oben erwähnten Datenspeicher (Elasticsearch und Redis) zu füllen und zu aktualisieren.

Die Zahlen der beiden Komponenten sind beeindruckend: 50ms für die Berechnung einer Seite sind der Benchmark für Yves und Zed sollte in 100ms bis maximal 150ms antworten – wohlgemerkt ohne Cache!

DWH

Die dritte Komponente ist das Datewarehouse (ohne spannenden Titel, einfach DWH), was für das ganze Reporting und die Auswertungen zuständig ist.
Es basiert auf einigen OpenSource-Komponenten und ist, obwohl ein für das Skalieren von Geschäftsmodellen sehr spannender Part, leider ein wenig zu kurz gekommen während der Präsentation.

Das Kernsystem ist sehr schlank und lose gekoppelt, so dass sich einzelne Komponenten möglichst einfach austauschen lassen sollen. Die einzelnen “Bundles” werden per Composer installiert und können damit nach Bedarf integriert werden.

Man sieht, was Fabian Wesner, CTO und Architekt von Spryker sich vorgenommen hat, wird hier konsequent umgesetzt: Best Practices der PHP-Webentwicklung sind an allen Stellen zu finden. Dies soll neben einer möglichst lange hoch bleibenden Entwicklungsgeschwindigkeit auch das OnBoarding neuer Entwickler vereinfachen.

Pricing

Natürlich sind Zahlen diskutiert worden, Aus dem Gefühl heraus würde ich sagen: Man ist noch auf der Suche nach einer tragenden Lösung. Spannend ist, dass man eben nicht wie die etablierten Hersteller die Lizenz an die Skalierung binden möchte. Benötigt man mehr Server oder übersteigt künstlich gezogene Umsatzgrenzen, muss nicht neue lizensiert werden. Damit läuft es auf eine Jahresgebühr hinaus. Diese soll pro Kunde einen Entwickler finanzieren, wie auch hier schon erwähnt. Zugegeben ein ziemlich gut bezahlter Entwickler. Dies ist für große Kunden sicher kein Problem, wenn sich dadurch eben auch einen Entwickler pro Jahr weniger mit dem Basissystem beschäftigen muss.

Zielgruppe

Das bringt uns zur Frage der Zielgruppe, die selbstverständlich auch in Berlin aufkam: “Für wen ist Spryker gedacht und interessant?” Die Antwort wurde leider zuerst vor allem mit dem Budget gegeben. Schade eigentlich. Ich finde die Zielgruppe ist sehr klar zu definieren:

Unternehmen, die einen wirklich agilen Ansatz haben oder wollen UND mittelfristig in der Lage sind, ein eigenes Team aufzubauen, dass das nötige Know-How aufbringen kann um solche eine Plattform stabil zu halten, zu warten und weiter zu entwickeln.
Denn wie haben die Kollegen von hmmh schön gesagt: “Mit Entwicklern ohne das entsprechende Rüstzeug ist auch dieses System in kürzester Zeit klein zu bekommen.”

Im Gegensatz zu den bisher am Markt verfügbaren Lösung hat Spryker eben keine Konfigurationsoptionen in einem Backend. Wenn ich so auf unsere Projekte schaue, dann begrüße ich den Ansatz sehr. Dies kann der Software nur gut tun – aus Sicht eines Technikers.

Statemachine und Stand der Software

Im zweiten Teil des Nachmittags teilte sich die Gruppe in “Sale” und “Technik”. Nicht schwer zu erraten, wohin ich gegangen bin.

Fabian Wesner hat uns in kleiner Runde Detailfragen beantwortet und uns den aktuellen Stand in einem Stagesystem erklärt.

Sehr spannend fand ich die Statemachine, mit der sich Bestellstatus sehr transparent darstellen und umsetzen lassen. Dies habe ich noch in keinem System so gut umgesetzt gesehen. Zum einen wirkt es den oft sehr undurchsichtigen Codeteilen mit unmengen von if-Statements entgegen, zum anderen ist auch für den Support äußerst transparent nachvollziehbar, warum eine Bestellung welchen Status hat. Laut eigenen Aussagen lassen sich damit auch shop mit 1.000 Bestellungen / Tag mit einem Team von 2 Personen im Support betreiben.

Was in diesem zweiten Teil aber auch klar wurde: Yves&Zed kam bisher nur bei Project A zum Einsatz. Die Aufgaben und Anforderungen, die an eine Produktlösung gestellt werden (müssen), sind noch nicht richtig erkennbar. Viele der Features müssen nochmal überarbeitet, korrigiert und angefasst werden. So ist zum Beispiel Zed derzeit noch in ZendFramework umgesetzt und soll wie oben erwähnt auf Silex portiert werden.
Der Umbau soll bis Ende Februar abgeschlossen sein. Dann sollen auch erste Agenturen mit der Implementierung beginnen können. Sie werden dabei eng mit Project A zusammenarbeiten (müssen).

Dies ist aus meiner Sicht sinnvoll, da man mit Spryker neben der Software auch viel Know-How was den Ausbau und die Skalierung der eigenen Online-Strategie betrifft mitbekommt und mitbekommen muss. Sonst wird man damit nicht glücklich werden.

Fazit

Mit Spryker kommt eine Lösung auf den Markt, die, einmal einen stable-Status erreicht, sicher etwas für Unternehmne wie uns, die eine agile Entwicklungsweise schätzen und leben und schnell auf Änderungen am Markt reagieren wollen, darstellen kann. Massentauglich wird sie erstmal nicht werden und soll sie ja auch nicht. Es wird daher aber immer die Note “Nischensystem” bleiben, bei er man sich der Frage stellen muss:
Wie lange trägt das ganze und wie zukunftssicher kann ich damit agieren.

Die Macher haben neben den Technischen Feinheiten vor allem die Aufgabe, Features (Bundles genannt) zu beschreiben, so dass klar ist, auf welche Komponenten zurück gegriffen werden kann. Derzeit gibt es noch keinen Importer für Daten und auch das Thema “PIM” ist konsequent ausgeklammert.

Was mir persönlich vor allem fehlt ist das wirklich “Neue”. Wer sich moderne Marketingkomponenten auf die Fahnen schreibt, muss sich fragen lassen, ob ein klassischer Kategoriebaum wirklich dem gerecht werden kann, oder ob es mit Elasticsearch an Bord nicht spannendere, flexiblere Ansätze gibt.

Ich hoffe bald wieder von diesem System zu hören und würde mir wünschen das Team im März beim eCommerceCamp in Jena zu sehen.

Joscha Krug ist Gründer und Geschäftsführer der marmalade GmbH aus Magdeburg. Mit seinem stetig wachsenden Team realisiert er schon seit 2009 E-Commerce Projekte mit OXID eShop und Shopware. Er ist Autor der beiden OXID Bücher, erschienen bei o'Reilly.

8 Kommentare zu:

Spryker – eine erste Einschätzung

  • Pingback: Spryker – Ein Blick hinter die Kulissen | ShopTechBlog

  • Simon Deichsel

    Nur am Rande: In mindestens einem Projekt verwendet ProjectA einen Kategoriebaum, der komplett auf Elastic-Search aufgebaut war. Das geht also durchaus mit Spryker.

  • Joscha Krug Artikelautor

    @Björn: Na, da folgen sicher noch ein paar.

    @Simon: Ja, das habe ich mir gedacht. Bauen, das ist gestern klar geworden, kann man damit sehr viel. Die Frage bleibt doch aber, wie der Standard aussehen wird.

  • Joscha Krug Artikelautor

    Lars Jankowsky hat sich auf Facebook geäusert und mir erlaubt, das hier aufzunehmen:

    Spryker ist richtig gut.

    ongr.io entspricht ja nur “Yves”. Es kann mehr als Yves weil das eben alles ist was wir tun und ongr.io ist gebaut worden um vor einen bestehenden Shop gesetzt zu werden, Yves hat nur Zed als Partner. (Natürlich könnte man das Ding auch manuell woanders hinverpflanzen aber ganz so einfach ist es eben nicht)

    Hauptunterschied: ongr.io kostet nichts, wer die Lizenzkosten von Spryker in die Hand nimmt und bei NFQ investiert bezahlt nicht “einen Entwickler bei Spryker” sondern bekommt 2 Entwickler für sich selbst. Kann man aber auch bleiben lassen und gar nichts bezahlen

    Nach vielen vielen Jahren Shopsoftware glaube ich zudem das Project A die Anforderungen aus dem Massenmarkt unterschätzt. Consulting, Professional Services, ein funktionierendes Ecosystem aus Agenturen und auch eine Infrastruktur für Kundenwünsche sind nicht zu unterschätzen. All das gibt es bislang nicht. Alexander Graf und seine Jungs machen hier sicher super Arbeit, das ist ja eine richtig gute Agentur – aber aus meiner OXID Zeit kann ich sagen das andere Agenturen da sehr misstrauisch reagieren wenn der Hersteller selbst Endkunden Projekte implementiert. Das ist eine dünne Linie auf der da balanciert wird.

    Abschliessend: Für mich stellt sich nicht die Frage “ongr” oder spryker. Beide Software machen zwar teilweise etwas ähnliches, zielen aber auf einen komplett anderen Markt.

    Spryker steht in Mitbewerb für Hybris, Intershop, Magento und auch OXID. Enterprise Kunden und Pure Player welche serious Business machen wollen sind hier die Zielgruppe.

    ongr.io zielt auf Hochlast Kunden, welche eben NICHT ihre Shopsoftware auf einen Rutsch ersetzen wollen – die Implementations Zeiten (und Kosten!) sind natürlich um ein vielfaches geringer. Nicht weil ongr “besser” ist sondern weil es keine Lizenzkosten gibt und ongr auch “nur” das Frontend ersetzt und das bestehende Backend bleibt.

    Schlussendlich stehen hier auch zwei Philosophien gegeneinander – FOSS vs. Kommerziell.

  • Pingback: TWiST #35: Shoptech-Szene diskutiert Spryker | ShopTechBlog

  • Andreas Ziethen

    Spannend! – Da tut sich jahrelang nix Nennenswertes auf dem Shop-Markt und jetzt liegen plötzlich 2 neue spannende Lösungen vor, die einen ähnlichen Ansatz haben und die im Grunde das umsetzen, was ich 2011 schon mal auf der OXID Commons als Gedankenspiel vorgetragen hatte, nämlich die Aufteilung in unterschiedliche Services, die auf das spezialisiert sind, was sie zu leisten haben. Das ist m. E. der richtige Weg für die nähere Zukunft und bringt in Sachen Wartbarkeit und Skalierbarkeit viel mehr Struktur und Ordnung rein.
    Wir arbeiten derzeit ja mit Foxx bzw. ONGR.io – aufsetzend auf einen OXID-Checkout – und sind bisher sehr zufrieden damit. Da wir aber auch den Checkout noch in unsere eigenen Hände nehmen wollen, werde ich mir gerne auch Spryker mal genauer ansehen. Bin da aktuel für alle Anregungen dankbar.

    Gibt es eigentlich schon irgendwo Zahlen bzgl. Spryker? Lizenzkosten? Supportvertrag? Wäre ja nicht ganz uninteressant …

    Gruß!
    Andreas

  • Pingback: Die Spryker-Debatte um die E-Commerce-Systeme der Zukunft | Exciting Commerce

  • Hinterlasse einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert