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