Support f├╝r Drupal 8 endet schon 2021

Auf seiner traditionellen "Driesnote" bei der Drupal Europe in Darmstadt (siehe oben stehendes Video) hat Drupal-Gr├╝nder Dries Buytaert verk├╝ndet, dass die kommende Version 9 von Drupal definitiv im Verlauf des Jahres 2020 erscheinen wird. Gleichzeitig wurde die kontrovers diskutierte Entscheidung ver├Âffentlicht, dass die aktuelle Version 8 von Drupal nur noch bis Ende 2021 supported werden wird. Grund ist das Auslaufen der Unterst├╝tzung f├╝r die von Drupal 8 verwendete Version von Symfony, welche ebenfalls f├╝r das Ende des Jahres 2021 angek├╝ndigt ist. Damit wird Drupal 8 noch genau so lange supported wie Drupal 7, dessen Unterst├╝tzung wiederum verl├Ąngert wird und dann ebenfalls zum Jahresende 2021 ausl├Ąuft.

Mit dieser Entscheidung bricht Drupal massiv mit der bisherigen Tradition. Bisher war es so, dass eine Drupalversion immer bis zum Erscheinen der ├╝bern├Ąchsten Version supportet wurde. Sprich, Drupal 5 verlor seine Unterst├╝tzung beim Erscheinen von Drupal 7, die Version 6 war ab dem Release-Datum von 8 "end of life". Nun wird es erstmals so sein, dass der Support sowohl f├╝r den Vor-Vorg├Ąnger als auch den direkten Vorg├Ąnger der neuen Version enden wird, nachdem das aktuelle Release erst ein gutes Jahr am Markt sein wird.

War es das f├╝r Drupal 8?

Websitebetreiber, die Drupal entweder einsetzen oder den Einsatz planen, werden diese Ank├╝ndigung erst einmal mit Schrecken vernehmen. Was bedeutet das f├╝r das D8-Projekt, das gerade im Bau ist? Muss es in nur 3 Jahren schon wieder ersetzt werden? Was bedeutet das f├╝r ein Projekt, bei dem Drupal 8 eingesetzt werden soll? Macht es jetzt ├╝berhaupt noch Sinn, damit anzufangen, oder wartet man lieber auf Drupal 9?

Auch f├╝r Dienstleister, die mit Drupal arbeiten, wird die Situation schwierig. Denn sie m├╝ssen genau diese ├ängste und Vorbehalte nun adressieren, wollen sie nicht anderthalb Jahre lang warten, bis die Kunden sich wieder "trauen", auf Drupal zu setzen. Hier hilft daher nur genaue Aufkl├Ąrung, was diese Entscheidung f├╝r die Weiterentwicklung Drupals wirklich bedeutet, und warum sie letztlich gar nicht so dramatisch sein d├╝rfte.

Drupal 7 vs. Drupal 8 - Unterschiede in der Produktentwicklungsstrategie

Um einsch├Ątzen zu k├Ânnen, was ein Wechsel von Drupal 8 auf 9 bedeuten k├Ânnte, muss man sich erst einmal vergegenw├Ąrtigen, was ein Wechsel von D7 auf D8 hei├čt. D8 war ein fast vollst├Ąndiger Rewrite des Systems, es hat mit D7 also nur sehr wenige technische Gemeinsamkeiten. Das Ziel beim Wechsel von D7 nach D8 war es unter anderem, Altlasten loszuwerden und auf neue, quelloffene Frameworks wie Symfony zu setzen. Das hei├čt: au├čer dem Namen und gewisser Konzepte haben Drupal 7 und 8 eher wenig gemein, es sind eigentlich zwei unterschiedliche Content-Management-Systeme. Entsprechend war auch ein "Upgrade" von D7 auf 8 praktisch unm├Âglich. Wer von D7 auf D8 wechseln wollte, kam an einem kompletten Relaunch seiner Website oder Applikation nicht vorbei.

Nun ist die Strategie, alte Z├Âpfe abzuschneiden und sich voll auf neue, effizientere Technologien zu konzentrieren aus Produktentwicklersicht sehr attraktiv. Enterprise-Nutzer indes, die extrem hohe Summen in sehr komplexe Projekte investieren, die sich ├╝ber den Zeitraum von Jahren hinweg amortisieren m├╝ssen, haben ein gro├čes Problem mit dieser Vorgehensweise. Die Zeit- und Geldmittel, die in solche Projekte flie├čen, sind einfach zu gro├č, als dass man das Investment alle paar Jahre komplett wiederholen k├Ânnte. Enterprise-Kunden ben├Âtigen vielmehr Systeme, die sich graduell entwickeln, ohne dabei das Absto├čen von Altlasten oder das Einsetzen neuer Technologien au├čen vor zu lassen.

Genau diesem Bed├╝rfnis tr├Ągt Drupal seit der Version 8 Rechnung. W├Ąhrend der Kern der Vorversion 7 seit deren Erscheinen im Jahr 2011 praktisch unver├Ąndert geblieben ist und nur noch Sicherheitsupdates erh├Ąlt, erh├Ąlt Drupal 8 seit seinem Release Ende 2015 in einem Halbjahreszyklus tats├Ąchlich auch nennenswerte Upgrades und Ver├Ąnderungen im Kern. Das hei├čt: w├Ąhrend D7 seit Erscheinen mehr oder weniger "eingefroren" ist, entwickelt D8 sich graduell weiter und kommt damit genau den eben angesprochenen Bed├╝rfnissen der Enterprise-Kunden entgegen. Das l├Ąsst sich sogar an der Nomenklatur der Versionsnummer ablesen. W├Ąhrend Drupal 7 immer direkt nach der Releasenummer hochz├Ąhlt (7.59 mit Stand April 2018), hat Drupal 8 eine dreiteilige Versionsnummer (8.5.4 mit Stand vom 6. Juni 2018). Nach der Releasenummer steht die zweite Ziffer nun f├╝r ein Upgrade (also funktionale ├änderungen am Kern), und erst die dritte Nummer kennzeichnet Updates (also lediglich Verbesserungen und Fixes).

Es gibt also seit Drupal 8

  • ebenfalls Patch-Releases (die eben angesprochenen Sicherheitsupdates und Detailverbesserungen, wie schon in Drupal 7 auch, und die nun durch die dritte Ziffer in der Versionsnummer gekennzeichnet sind)
  • nun aber neu auch Feature-Releases (manchmal auch als Minor Releases bezeichnet), die das System tats├Ąchlich um neue Funktionen erweitern, und f├╝r die die zweite Ziffer in der Versionsnummer steht

Letztere sind besonders interessant, denn sie adressieren das Problem von "Upgrade-Schwellen".

Upgrade-Schwellen

In jeder Software, die neue Versionen bekommt, existieren "Upgrade-Schwellen" unterschiedlicher H├Âhe. Wie beschrieben, ist die Upgrade-Schwelle zwischen D7 und D8 praktisch un├╝berwindbar - man kann sie nur umgehen durch einen Produkt-Relaunch und einer Migration. Zwar ist beispielsweise der Migrationsaufwand hier immer noch geringer als von einem Drittsystem zu Drupal - aber nichtsdestotrotz sind die Aufw├Ąnde sehr gro├č. Das Ziel bei der Weiterentwicklung von Drupal ab Version 8 war es daher von Beginn an, beim n├Ąchsten Major-Release (also der Sprung von 8 nach 9) diese Upgrade-Schwelle so niedrig wie m├Âglich halten zu k├Ânnen. Aber wie erm├Âglicht man das? Die technische Entwicklung bleibt nicht stehen, und komplexe Software wie Drupal es ist, muss dieser Entwicklung Rechnung tragen, um am Markt bestehen zu k├Ânnen. Technische Weiterentwicklung bedingt aber auch Inkompatibilit├Ąten zu fr├╝heren L├Âsungen, die es dann auszur├Ąumen gilt.

Wie l├Âst Drupal das? Fakt ist, dass Upgrade-Schwellen sich nicht vermeiden lassen, will man das System auf dem aktuellen Stand des technisch m├Âglichen halten. Die Produktentwicklungstrategie seit Drupal 8 ist daher, die Schwellen nicht als einzelne hohe H├╝rde zwischen den Major-Releases zu platzieren, die entweder gar nicht oder nur mit immensen punktuell anfallenden Kosten bew├Ąltigt werden kann. Statt dessen werden nun viele, daf├╝r aber relativ niedrige Schwellen innerhalb des Major-Release platziert. Wie angesprochen, erscheint halbj├Ąhrlich eine neue Version von Drupal 8, bei der sich die zweite Ziffer in der Versionsnummer ├Ąndert (z.B. von 8.4.x auf 8.5.x). Diese "Feature-Releases" stellen nun die Upgrade-Schwellen dar.

Was hei├čt das nun f├╝r den Produktiveinsatz?

Da seit Drupal 8 die Upgrade-Schwellen innerhalb des Major-Release verortet sind, und nicht mehr nur zwischen den Major-Releases, entstehen bei Drupal 8 tendenziell etwas h├Âhere Wartungsaufw├Ąnde als beim Drupal 7-Betrieb. Au├čerdem ist der "Druck" h├Âher geworden, das System sauber zu implementieren und auch regelm├Ą├čig instand zu halten. Zwar laufen Upgrades zwischen zwei Feature-Releases innerhalb von Drupal sp├Ątestens seit Version 8.3.x relativ problemlos durch, sofern eine Seite solide und gem├Ą├č der Coding-Standards f├╝r Drupal entwickelt wurde. Wenn das System allerdings mangelhaft implementiert ist oder auch wartungstechnisch vernachl├Ąssigt wurde, ist die Wahrscheinlichkeit jetzt noch h├Âher als bei Drupal 7, in ernste Probleme zu geraten und erh├Âhte Wartungsaufw├Ąnde tragen zu m├╝ssen, wenn dann doch irgendwann ein Upgrade auf die aktuelle Version versucht wird.

Das hei├čt also f├╝r Betreiber wie f├╝r Dienstleister: sie m├╝ssen mehr noch als bei Drupal 7 darauf achten, die Aufw├Ąnde f├╝r den Betrieb und die regelm├Ą├čige Aktualisierung eines Drupal 8 Projektes einzukalkulieren, und sich auch disziplinieren, diese Upgrades durchzuf├╝hren, respektive auf Kundenseite einzufordern. Denn nur so ist gew├Ąhrleistet, dass das Projekt von der Produktentwicklungsstrategie Drupals seit der Version 8 profitiert.

Und die guten Nachrichten?

Auszahlen wird sich diese Strategie bei einem neuen Major-Release, also beim Erscheinen von Drupal 9. W├Ąhrend die Upgrade-Schwelle zwischen Drupal 7 und Drupal 8 praktisch un├╝berwindbar war, wird sie zwischen 8 und 9 sehr viel niedriger liegen. Tats├Ąchlich lautet das Versprechen von Drupal-Gr├╝nder Dries Buytaert, dass das Upgrade einer stets gepflegten und sauber umgesetzten Drupal 8 Instanz in der letzten Feature-Release-Version auf Drupal 9 nur unwesentlich komplexer und aufw├Ąndiger ausfallen wird, als es die Upgrades zwischen zwei Feature-Releases von Drupal 8 gewesen sind.

Ob das in der Praxis so funktionieren wird, muss sich nat├╝rlich erst erweisen. Es gibt Risiken, die man nicht ignorieren darf, etwa beim Einsatz von Erweiterungen (Contrib-Modulen) von Drittentwicklern, wenn diese auf veralteten Programmierschnittstellen (APIs) aufbauen. Insbesondere bei gro├čen Webprojekten mit vielen Contrib-Modulen kann hier beim Versionswechsel durchaus Anpassungsbedarf bestehen, der ├╝ber ein "einfaches" Upgrade hinaus geht.

Aber sicher ist: Drupal 8 wird nach Drupal 9 upgradebar sein, denn dieses Ziel war bei der Entwicklung von Drupal 8 von Beginn an eine zentrale Vorgabe. Somit wird ein Wechsel zwischen dem aktuellen und dem kommenden Major-Release definitiv mit einem Bruchteil der Kosten m├Âglich sein, der in der Vergangenheit f├╝r einen Wechsel von D7 nach D8 angefallen ist - denn hier brauchte der Kunde im Regelfall eine komplett neue Website, und alle Individualleistungen in Bezug auf Informationsarchitektur, Layout, Design, abgebildete Arbeits- und Datenverarbeitungsprozesse etc., die zuvor f├╝r das alte System erbracht wurden, und die die eigentlichen Kosten eines auf Open Source Software basierenden Webprojekts darstellen, mussten erneut erbracht werden.

Und dies ist die zentrale Botschaft f├╝r alle, die das Erscheinen von Drupal 9 nicht ohnehin zum Anlass nehmen wollen oder k├Ânnen, ihr Projekt komplett zu erneuern: sie k├Ânnen den Relaunch schon jetzt auf Drupal 8 durchf├╝hren, und m├╝ssen sp├Ąter lediglich ein Systemupgrade von D8 nach D9 vornehmen, ohne die Individualleistungen alle erneut implementieren zu lassen. Da die Individualleistungen im Regelfall das gr├Â├čte Investment bei einem Webprojekt sind, kann dieses Investment somit k├╝nftig beim Upgrade auch komplexer Projekte von D8 auf D9 weitgehend erhalten bleiben und geht nicht verloren, wie es beim Wechsel von Drupal 7 auf 8 noch unvermeidlich war.

Selbst wenn also gesteigerte Aktualisierungsaufw├Ąnde beispielsweise durch die Notwendigkeit der Anpassung von Drittmodulen entstehen, weil diese noch nicht auf die aktuellen Programmierschnittstellen abgestimmt sind, so ist das immer noch ein um viele Gr├Â├čenordnungen geringeres Investment, als ein erneuter Relaunch. Der Gewinn aus diesem Investment ist jedoch immens. Denn durch das Upgrade auf D9 bleiben nicht nur die f├╝r D8 entwickelten Individualleistungen weitgehend erhalten, sondern der Kunde kann das System versions├╝bergreifend sogar deutlich l├Ąnger betreiben, als es je zuvor mit Drupal m├Âglich war. Dies ist insbesondere f├╝r geschlossene Systeme wie beispielsweise Intranets oder interne Webapplikationen interessant, da deren Erneuerungszyklen in der Regel deutlich weiter auseinanderliegen als bei ├Âffentlichen Websites, wo in der Regel schon nach 4 bis 6 Jahren Betriebszeit zumindest ├╝ber einen "Facelift" nachgedacht wird.

Das Major Release als psychologische H├╝rde

Rein technisch klingt das alles erst einmal gro├čartig, und es ist genau die Strategie, die Enterprise-Kunden, die ├╝ber einen Zeitraum von vielen Jahren Planungssicherheit ben├Âtigen, bei einem CMS-Framework erwarten. Dennoch ist ein Wechsel der Versionsnummer immer noch eine H├╝rde - hier insbesondere eine psychologische. Vor allem Kunden, die mit der Problematik des Wechsels von D7 nach D8 vertraut sind, werden wie eingangs bemerkt gro├če Vorbehalte und Bedenken haben, neue Drupal 8-Projekte zu beginnen, wenn sie glauben, das Investment in die erforderlichen Individualleistungen dann in nur wenigen Jahren wiederholen zu m├╝ssen. Diese Vorbehalte k├Ânnen nur ausger├Ąumt werden, wenn sie verstehen und nachvollziehen k├Ânnen, dass der Wechsel von Drupal 8 auf 9 eine um ein Vielfaches niedrigere Upgrade-Schwelle bedeuten wird, welche Methoden verwendet werden, um das zu erreichen, und dass es eben sehr wichtig ist, in die hierf├╝r notwendigen Betriebs- und Wartungsaufw├Ąnde zu investieren. Dies sollte zwar sowieso selbstverst├Ąndlich sein, wenn man sein D8-Projekt ordentlich betreibt. Es ist aber praktisch alternativlos, wenn man sein D8-Projekt perspektivisch unter D9 weiterbetreiben m├Âchte.

Fazit

Der verk├╝rzte Lebenszyklus von Drupal 8 klingt erst einmal wie ein gro├čer Nachteil f├╝r die Konkurrenzf├Ąhigkeit von Drupal. Dies werden Mitbewerber sicherlich auch nutzen, indem sie die Situation unvollst├Ąndig darstellen werden, um Angst und Zweifel beim Kunden gegen├╝ber seiner Pr├Ąferenz f├╝r Drupal zu erzeugen. Jedoch ist die Situation bei Lichte besehen gar nicht so dramatisch. Durch die bereits mit Drupal 8 eingef├╝hrte Entwicklungspolitik, Upgrade-H├╝rden nicht mehr zwischen zwei Major-Releases zu platzieren, sondern diese Schwelle auf innerhalb eines Major-Releases in regelm├Ą├čigen Abst├Ąnden ver├Âffentlichte Feature-Releases zu verteilen, bleibt der Kern von Drupal 8 technisch nicht "eingefroren", wie es bei der Vorg├Ąngerversion der Fall war. Vielmehr entwickelt sich Drupal 8 graduell bereits in die Richtung von Drupal 9 weiter. Softwarearchitektonische Entscheidungen, die f├╝r Drupal 9 getroffen werden, werden direkten Einfluss auf die Weiterentwicklung von Drupal 8 haben, und es wird mit Sicherheit sehr viel Energie und Einsatz darauf verwendet werden, den letztlichen ├ťbergang von einer Version zur anderen so komfortabel und einfach wie m├Âglich zu machen.

Wer auf Drupal 9 warten kann, kann dies nat├╝rlich tun. Wer nicht darauf warten kann, sollte nach wie vor auf Drupal 8 bauen und sich vergegenw├Ąrtigen, dass die Entwicklungspolitik von Drupal ja genau hierf├╝r ge├Ąndert wurde: Verl├Ąsslichkeit, Langfristigkeit, Upgradef├Ąhigkeit. Alle drei unverzichtbare Aspekte im Business-Bereich und damit starke Argumente daf├╝r, warum Drupal im Enterprise-Sektor immer beliebter wird.

Profilfoto Fabian Lorenzen

Fabian Lorenzen

Gesch├Ąftsf├╝hrer / Projekt Manager