Kopflos, SaaS und warum das nicht unbedingt zusammengehört

Ich beobachte, dass neue Käufer von Content Management Systemen (CMS) einem Irrglauben aufsitzen. Dieses Missverständnis gibt es schon seit Jahren und es scheint nicht verschwinden zu wollen.

Die Leute verwechseln zwei Konzepte:

• Ein Hosting-Modell, das definiert, wie Ihr Unternehmen mit Ihrem Softwareanbieter und der Umgebung, in der Ihre Website läuft, zusammenarbeitet. Software-as-a-Service (SaaS) und Platform-as-a-Service (PaaS) sind Hosting-Modelle.
• Eine Bereitstellungsarchitektur, die die Beziehung zwischen dem Ort, an dem Ihre Inhalte verwaltet werden, und dem Ort, an dem sie bereitgestellt werden, definiert. Headless und Coupled (und die seltenere Decoupled) sind Bereitstellungsarchitekturen.

Es handelt sich dabei nicht um dasselbe, denn Engagement-Modelle und Bereitstellungsarchitekturen können miteinander kombiniert werden.

Ich werde beides weiter unten erklären. Ich denke, Sie werden feststellen, dass sie so unterschiedlich sind, dass ich im Grunde zwei nicht miteinander verbundene Blogbeiträge schreibe.

Hosting-Modelle

Vor zwanzig Jahren installierten Sie Ihr CMS häufig auf Servern, die Sie selbst besaßen. Dann erstellten Sie Ihre Website mit diesem CMS und installierten sie auf demselben Server.

(Ich erinnere mich, wie ich einmal in einem kalten Rechenzentrum stand und Ektron von einer CD-ROM auf einen Rack-Server lud. Das dauerte eine Weile, man konnte sich nirgends hinsetzen und es war eiskalt. Davon haben wir uns weit entfernt.)

Ein paar Jahre später verlagerten die meisten Unternehmen ihr Hosting auf externe Unternehmen. Es war im Grunde das gleiche Modell, aber Sie installierten einfach das Gleiche bei Unternehmen wie Rackspace, SoftLayer und - später - AWS (Amazon Web Services) und Microsoft Azure.

Das ist es, was noch immer als On-Premise Hosting (oft abgekürzt mit "on-prem") bezeichnet wird, auch wenn es sich manchmal nicht tatsächlich in den Räumlichkeiten des Kunden befindet. In diesem Fall übernimmt der Kunde die vollständige Verantwortung für seine Hosting-Umgebung - er erstellt die Lösung und hostet sie. Bei diesem Modell hat der CMS-Anbieter keine Beziehung zu all dem, er verkauft und unterstützt lediglich die Software.

Heute ist dieses Hosting-Modell weit weniger verbreitet. Da die Unternehmenssoftware immer komplexer wird und immer mehr Dienste auf Cloud-Computing umgestellt werden, haben die Softwareanbieter maßgeschneiderte Plattformen für den Betrieb ihrer Software entwickelt. Heutzutage kaufen Sie keine Software mehr, sondern Sie gehen eine dauerhafte Beziehung mit einem Anbieter ein, um Ihr Projekt auf dessen Plattform zu erstellen und zu installieren.

Dies wird Platform-as-a-Service oder "PaaS" genannt. (Normalerweise wird es "pass" ausgesprochen, aber manchmal mit einem "z", so dass es sich auf "jazz" reimt.)

Bei PaaS ist es immer noch Ihr Projekt. Sie führen Ihre individuelle Integration und Programmierung mit den vom Anbieter bereitgestellten Softwaretools durch. Ihre Optionen sind weit offen. Sie treffen alle Entscheidungen, und die einzige Grenze ist, welche Tools und Funktionen die Software zur Verfügung stellt.

Manche Kunden sind in ihren Bedürfnissen enger gefasst. Sie sind bereit, funktionale Einschränkungen in ihrer Software zu akzeptieren, wenn sie im Gegenzug einen Service nutzen können, den jemand anderes entwickelt hat. Anstatt auf einer Plattform aufzubauen, mieten diese Kunden einen definierten Dienst, für den sie keinen eigenen Code schreiben oder installieren können. Stattdessen bewegen sie sich durch Zeigen und Klicken durch eine Schnittstelle.

Dieses Modell wird Software-as-a-Service oder "SaaS" genannt. (Ausgesprochen wie "Sass". Sie wissen schon, wie das, was wir von unseren Kindern zu viel bekommen...)

SaaS-Software ist von vornherein begrenzt. Sie akzeptieren die Konventionen und Meinungen von jemand anderem. Solange Ihre Bedürfnisse mit der Art und Weise übereinstimmen, wie die Software entwickelt wurde, mag das gut funktionieren.

Aber bei SaaS bauen Sie nicht auf einer Plattform auf. Ihre Möglichkeiten sind darauf beschränkt, wie der Anbieter Ihnen erlaubt, seine Software neu zu konfigurieren. Wenn die Software des Anbieters etwas Bestimmtes nicht kann, was Sie brauchen, müssen Sie Ihre Pläne oft ändern, um sie an die Funktionsweise der Software anzupassen.

(Fairerweise muss gesagt werden, dass diese Systeme unterschiedlich sind und manche viel mehr Leistung und Konfigurationsmöglichkeiten bieten als andere. Aber der springende Punkt ist: Sie müssen sich mit dem begnügen, was sie anbieten.)

Eine praktische Analogie ist das Wohnen:

• On-Premise Hosting ist wie der Besitz eines eigenen Hauses. Sie können tun und lassen, was Sie wollen, und was passiert, ist Ihr Problem.
• Platform-as-a-Service ist wie der Besitz einer Eigentumswohnung. Sie befindet sich in einem Gebäude, das jemand anderem gehört und von ihm gewartet wird. Aber Sie können in Ihrer eigenen Wohnung machen, was Sie wollen. Reißen Sie alle Wände ein, installieren Sie einen Basketballplatz usw. Solange Sie nichts außerhalb Ihres eigenen Bereichs beeinträchtigen, können Sie sich austoben.
• Software-as-a-Service ist wie die Anmietung einer Wohnung. Ihrem Vermieter gehört das Gebäude, und ihm gehört auch Ihre Wohnung. Ihre Couch ist zu lang für die Wand, an die Sie sie stellen wollen? Pech gehabt, kaufen Sie eine andere Couch.

Kommen wir nun zu etwas ganz anderem als dem Hosting: wie sich Ihre Verwaltungs- und Bereitstellungsumgebung überschneidet.

Architekturen für die Bereitstellung

Die Verwaltung von Inhalten und die Bereitstellung von Inhalten sind zwar miteinander verbunden, aber voneinander zu trennen. Die Art und Weise, wie sie sich überschneiden, wird als Bereitstellungsarchitektur oder Kopplungsmodell bezeichnet.

Allgemein ausgedrückt:

• Die Verwaltung ist alles, was Sie mit den Inhalten tun, bevor Sie auf die Schaltfläche "Veröffentlichen" drücken.
• Die Bereitstellung ist das, was danach kommt - die Prozesse und Tools, die Ihre Inhalte in ein konsumierbares Artefakt (z.B. eine Webseite) umwandeln und an denjenigen liefern, der sie haben möchte.

Diese beiden Prozesse können in derselben Computerumgebung (demselben Server oder einer Reihe von Servern) oder in getrennten Computerumgebungen (auf verschiedenen Servern, vielleicht sogar in verschiedenen Datenzentren auf verschiedenen Kontinenten) stattfinden. Wie diese beiden Prozesse zusammenhängen, ist eine Frage der Architektur.

Vor zwanzig Jahren war die häufigste Architektur Decoupled CMS. Die Verwaltung der Inhalte wurde von einem CMS übernommen, das Inhaltsartefakte (HTML-Dateien, Bilder usw.) generierte und sie an eine andere Serverumgebung weiterleitete, um sie zu konsumieren.

Bei dieser Architektur liegt das "Gehirn" der Operation auf der Verwaltungsseite. Sie entscheidet, welche Inhalte in eine "stumme" Bereitstellungsumgebung verschoben werden sollen. (Fairerweise muss man sagen, dass die Bereitstellungsumgebung durchaus anspruchsvoll sein kann, aber das muss sie nicht sein. Sie muss nur das ausliefern, was ihr zur Verfügung gestellt wurde.)

Dies hatte einige Vorteile in Bezug auf Stabilität und Leistung, aber es hatte auch eine Einschränkung, da wir durch die Abkopplung der Bereitstellung von der Verwaltung an Flexibilität verloren. Wir konnten nur eine Version unserer Inhalte erstellen und uns nicht auf ein angeschlossenes CMS verlassen, wenn es um Informationen über unsere Benutzer und deren Interaktion mit unseren Inhalten ging.

Da die Kundenbedürfnisse immer komplizierter wurden, ging die Branche zu einer so genannten Coupled CMS-Architektur über. Hier finden Verwaltung und Bereitstellung in der gleichen Umgebung statt. Die Redakteure verwalten die Inhalte, veröffentlichen sie, und dann werden sie von demselben System konsumiert. Die Inhalte sind immer mit dem CMS verbunden; die Besucher greifen nur auf die "andere Seite" des Systems zu.

Dies ist bei weitem die häufigste Architektur, die heute verwendet wird. In diesem Modell sind Verwaltung und Bereitstellung kombiniert und arbeiten zusammen - beide Seiten nutzen dasselbe Gehirn.

Da Ihre Bereitstellungsumgebung mit Ihrer Verwaltungsumgebung verbunden ist, können Sie viel interessantere Dinge mit Ihren Inhalten tun, z. B. sie in Echtzeit für verschiedene Besucher anpassen.

In den letzten Jahren ist ein Trend zu Headless CMS-Architekturen zu beobachten, bei denen die Verwaltungs- und die Bereitstellungsumgebung wieder getrennt sind. Anstatt jedoch Inhalte durch das CMS von der Verwaltungs- in die Bereitstellungsumgebung zu schieben, werden die Inhalte von der Website (oder der Mobile App oder was auch immer sie konsumiert - allgemein als "Kanal" bezeichnet) aus der Verwaltungsumgebung gezogen. Das CMS wird einfach zu einer dezentralen Inhaltsdatenbank, die einen dezentralen Endpunkt (eine so genannte "API") für die Kanäle zum Abrufen von Inhalten bereitstellt.

Bei Headless befindet sich das Hirn der Operation in der Bereitstellungsumgebung. Die Website (oder Mobile App oder was auch immer) ruft bei Bedarf Inhalte aus einem "dummen" CMS ab. (Das CMS muss nicht unbedingt "dumm" sein, aber es kann es sein, denn es muss lediglich Inhalte speichern und die angeforderten Inhalte bereitstellen).

Die Headless-Architektur wurde populär, als Kunden Inhalte an immer mehr Orten nutzen wollten und daher ein CMS benötigten, das nicht an einen bestimmten Kanal gebunden ist.

Außerdem sind JavaScript-Frameworks wie React so leistungsfähig geworden, dass Rohdaten in einen Webbrowser gezogen und dort mit Vorlagen versehen werden können, anstatt dies im CMS zu tun. Und durch die Trennung von Verwaltung und Bereitstellung können Kunden ihre Bereitstellungsarchitekturen mit einer anderen Technik entwickeln als die, auf der ihr CMS läuft.

Ein System kann ein reines Headless-System sein, das keine Vorlagen erstellt und nur Rohdaten an ein anderes System weiterleitet. Es kann aber auch ein hybrides Headless-System sein, das in einer traditionellen gekoppelten Architektur arbeitet, aber auch über Tools verfügt, mit denen Inhalte headless bereitgestellt werden können. Sie können beide Architekturen in einem System haben.

Wo sie sich überschneiden

Ich wiederhole noch einmal, was ich vorhin gesagt habe - ich habe oben im Grunde zwei nicht miteinander verbundene Blogbeiträge geschrieben.

Ich hoffe, es ist jetzt klar, dass das Hosting-Modell und die Bereitstellungsarchitektur einer Lösung technisch nichts miteinander zu tun haben.

In der Praxis tendiert der Markt jedoch in bestimmte Richtungen und Kombinationen, was zu der Verwirrung geführt hat.

• Die meisten Anbieter entfernen sich von allen On-Premise-Lösungen. Sie kaufen keine Unternehmenssoftware mehr, sondern leasen sie.
• Die meisten Anbieter, die reine Headless-Systeme entwickeln, haben sich das Software-as-a-Service-Modell zu eigen gemacht. Da ihre Systeme einen reduzierten Funktionsumfang aufweisen, lassen sie sich leichter als konfigurierbare Dienste betreiben.
• Hybrid-Anbieter tendieren zum Platform-as-a-Service-Modell. Diese Systeme eignen sich für komplexere Integrationsszenarien, so dass die Möglichkeit, Code zu schreiben, ein entscheidender Vorteil ist.

Es gibt Ausnahmen. Einige Open-Source Headless-Systeme können vor Ort installiert werden. Und es gibt traditionell gekoppelte Anbieter, die ihre Software als Service verkaufen. Und es gibt, wenn auch selten, einige hybride Headless SaaS-Anbieter.

Besonders erwähnenswert ist Optimizely, eine PaaS-Plattform mit allen möglichen Headless-Funktionen. Sie können also Headless nutzen und trotzdem Ihre eigene integrierte Lösung entwickeln und einsetzen.

Der springende Punkt: Wählen Sie aus, wie Sie diese beiden Modelle miteinander verknüpfen möchten. Wenn Sie mehr Kontrolle über Ihre Implementierung haben möchten, sollten Sie sich nicht mit einem SaaS-Hosting-Modell oder einer Headless-Architektur zufrieden geben, nur weil Sie glauben, dass "Headless SaaS" ein geschlossenes Paket ist.

Das ist es nicht. Das war es nie.