zondag 11 mei 2008

Drupal niet geschikt voor 'the enterprise'?

Via del.icio.us/popular/Drupal kom ik net het artikel '5 reasons why the Drupal CMS is not ready for the enterprise' tegen. Het is een vrij technisch verhaal over o.a.:
(1) het /de (?) 'front controller pattern' (bottleneck);
(2) de vele rijen code per 'request' die worden geladen ('load');
(3) de database-architectuur (één i.p.v. meer databases);
(4) nadelen van caching voor 'social networking' (ge'cache'te pagina's geven geen 'real-time' informatie zoals nodig voor 'wie is online', chatten en dergelijke);
(5) het gebruik van 'globals' in PHP (programmacode moeilijker te onderhouden).

Wat ik allemaal lees klinkt me logisch in de oren. De vragen die het bij mij oproept:
- Wanneer, bij welke grootte van een webproject / website worden één of enkele van de genoemde punten een probleem?
- En wat mag in de toekomst van de Drupal-developing-'community' en/of bedrijven zoals Lullabot en Acquai worden verwacht?

Tips / verwijzingen naar artikelen over de schaalbaarheid van Drupal zijn ook van harte welkom.
Maar bovenal lees ik graag inschattingen van de relevantie van de opgemerkte 'knelpunten' voor grote projecten, hoe daar mee om te gaan, alternatieven, etc ??

Update 21.30 uur: Lees de uitgebreide reacties van 'berkes' en Peter Bex.

4 opmerkingen:

Peter Bex zei

Ik kan de conclusies van deze persoon onderschrijven, uit ervaring. In Drupal zijn in het vroege begin enkele onhandige keuzes gemaakt die het systeem nu beginnen op te breken.

De "alles is een node" oplossing voor het opslaan van content is in principe erg flexibel. Je kunt willekeurig de betekenis van "node" uitbreiden met nieuwe datatypes, maar dat is ook een nadeel. Code moet vaak veel moeite doen om het "soort" node wat het beheert te kunnen onderscheiden. Ik heb in de praktijk al enkele keren gezien dat module A nodes van module B probeerde te beheren, met alle gevolgen van dien.

Wat betreft het gebruik van het frontcontroller pattern: Ik zie niet waarom dit inherent een probleem hoeft te zijn. Onafhankelijk van je architectuur weet je niet van te voren welke modules mogelijk nodig zullen zijn op de pagina, omdat modules in principe alles kunnen doen. Je zult dus toch alle code van iedere module altijd moeten laden. Dit kan opgelost worden door bijvoorbeeld de registratie van module "hooks" onafhankelijk te maken van de implementatie van die "hooks", maar dat kan dus ook met de huidige architectuur.

Om antwoord te geven op je vragen: De grootte van het project is niet echt bepalend voor wanneer het een probleem wordt. Het ligt voornamelijk aan welke modules je gebruikt en met elkaar combineert. Zo is meertaligheid bijvoorbeeld redelijk knullig opgelost waardoor voor iedere zin die vertaald moet worden apart de database wordt aangesproken. Gebruik je alleen de "systeemtaal" (Engels) of is er weinig vertaalbare content tegelijkertijd in beeld, dan valt het allemaal erg mee. Daarbij komt dat caching voorkomt dat de overhead te erg wordt. Over het algemeen kun je stellen: hoe meer verschillende modules je gebruikt, hoe zwaarder de site wordt.

Ik verwacht dat deze problemen door de bedrijven die aan Drupal ontwikkelen opgelost worden, al was het maar omdat je de problemen simpelweg moet oplossen als je grote sites gaat uitrollen. Maar dit gebeurt alleen als men bereid is sommige dingen in Drupal (zoals de node tabel) flink op de schop te nemen.

Ondanks dit toch negatieve verhaal ben ik erg blij met Drupal: het systeem zit behoorlijk goed in elkaar (een stuk beter dan Joomla bijvoorbeeld, wat deze persoon toch als "beter" aanduidt) en het heeft een heel actieve community. Het is een beetje onzin om te stellen dat MVC een vereiste is voor een goed werkend modulair systeem (het is frappant hoe sterk mensen geloven dat OO op de een of andere manier beter ontwerp impliceert). Sterker nog: de enorme hoeveelheid hoge kwaliteit modules voor Drupal zijn het bewijs dat de modulariteit van Drupal juist goed is en klaar voor de toekomst. Nou alleen de database structuur nog :)

berkes zei

Ach wat een onzin.

Wat deze man zegt is dat DRupal "niet geschikt is voor logge (ouderwetse) megaprojecten. Natuurlijk. Met een kruiwagen en een cementmolen leg je ook geen HSL aan.

Gelukkig is het Internet de HSL-projecten allang voorbij. Zeven kleine startups bereiken meer dan "weer een nieuw megaproject uit de pijplijn van Novell" kan.

Wat deze man zegt is daarom helemaal waar. En daar moeten we allemaal maar wat blij om zijn: Drupal is niet geschikt om in te zetten in projecten die niet geschikt zijn voor internet. Prima. Houden zo!

Drupal wordt met success ingezet door PCM, diverse publieke omroepen, door gemeentes, in immens veel kleine ideologische projecten, in nog meer persoonlijke projecten en inmiddels voor duizenden MKB sites. En dan hebben we het alleen nog maar over Nederland.

Nee wat zeurpit Hiveminds wil zeggen is dat hij het internet niet begrijpt. Deze malloot loopt al bijna drie jaar te eikelen over Drupal en is ook meerder malen met de staart tussen de benen weggerend omdat in een heftige discussie bleek dat hij de plank helemaal missloeg. GRappis is wel dat hij drie jaar na dato nog altijd veel met Drupal werkt.

Ook hier slaat hij diverse malen de plank falikant mis.
* FRont controller: IS veel meer dan een array. WElgeteld 2411 regels complexe PHP die tesamen een volledig en zeer flexibel routersysteem zijn. Ik ben slechts eenmaal een handiger en meer geavanceerd routersysteem tegegekomen in webdevlopment,. Dat was in Ruby on Rails en heet daar dan ook gewoon "router". Wat Carl hier schrijft is dat hij het router systeem niet begrijpt. En niet dat het niet klopt. Hij geeft gewoon zijn incompetentie toe.
* Drupal kan perfect data uit meerdere databases halen. Drupal kan info uit LDAP, Posgre, MySQL en nog veel meer, in een sessie, op een site halen. Een regelrechte leugen dus, als hij beweert dat dat niet kan. Eigenlijk denk ik dat het gewoon een nitwit is die wat geruchten en FUD naschreeuwt, zonder ze te verefieren
* OO. Het eeuwige Drupal is niet OO (object georiënteerd) argument. Ook regelrechte onzin. Drupal is inderdaad niet OO. Maar dat komt omdat PHP eenvoudigweg nauwelijks OO is. Van alle talen heeft PHP het minstte OO mogelijkheden. Zelfs in PHP5, waar het relatief een revolutie is (t.o.v. PHP4) is OO een lachtertje. En toch zijn er enorm veel successvolle projecten in geschreven. Zou Drupal echt een groter success zijn geweest als het in Python was geschreven. Inderdaad: Plone doet het stukken minder goed. De taal is echt van ondergeschikt belang aan de architectuur. En laat die nu net uitermate OO zijn in Drupal. Drupal is in essentie heel OO, zonder de technische implementatie van OO in de programmeertaal.
* Alles includen: Ook hier heeftg meneer een klepel horen hangen die er niet is. Of hoe dat spreekwoord ook gaat. Onzin. Drupal doet wel conditional includes en laadt zeker niet alle code in. Volgende punt.
* Niet MVC. Dit klopt. Drupal is MC en V, het heeft de M en de V op een laag. Is dat slecht? Niet perse. Dries heeft namelijk een heel sterk argument als hij zegt dat MySQL een abstractie ís. Dat het onziniig is daarbovenop nog een M abstractie te schrijven. Het is dus een keuze. geen tekortkoming.
* Caching. Ik heb gewerkt met wat meneer "corporate" systemen noemt. GX, Ecenic en dergelijke. Geen diepgravend werk, maar ik kan zeggen dat zij het nóg slechter hadden geregeld qua caching. De idee die Carl schept dat "Corporate == Good Caching" is dus, blijkens deze "real world examples" onjuist. Kortom: DRupal heeft een van de minst slechte caching systemen. Het kan beter, maar als dit een ijjkpunt was, dan was Drupal juist hét Corporate CMS.
* Refactoring en 3rd party gedoe: Carl geeft hier weer zijn eigen incompetentie toe. Dat doet hij constant. Wat hij hier wil zeggen is: Ik kan niet goed onderzoeken wat goede en wat slechte modules zijn. Drupal inzetten op dit niveau vereist kennis en kunde. Heb je die, dan zijn alle argumenten zoals hij die beschrijft moot. Ja: er zijn heel veel slechte modules. Leer dan ****domme hoe je een module moet reviewen en stop met huilen.
* Globals: welgeteld 1 global variablele op meer dan 10.000 variabelen. En over deze ene is iedereen het allang (jaren) eens dat die er eigenlijk niet moet en hoeft te zijn. Maar enderzijds uit een stukje nostalgie en anderzijds uit luiheid (om die ene weg te halen moet 80% van de code aangepast worden) blijft die er zitten. Totdat iemand deze modderpoel induikt en een patch hiervoor maakt. Ik denk overigens dat diegen tot Greatest Drupal Hero All Times gebombardeerd zou worden. Ook hier geldt mijn argument: wil je aan een paar onvolkomenheden in de code aflezen hoe geschikt een project voor "de corporate" is? En wil je dat aflezen ervan laten doen door iemand die, blijkens zijn andere missers (zie boven) nauwelijks zelf code kan schrijven of lezen?

Dus wat Carl zegt is meer dan waar: PHP is not Java. En blij toe. Kunnen we tenminste nog sites bouzen, in plaats van vechten met achterhaalde Design Patterns en complexe, trage servers, en werkend in onstabiele, onhandige ontwikkelomgevingen.

Om wat van je vragen te beantwoorden: Geen probleem Drupal, en eigenlijk de meeste CMSen op LAMP stacks hebben de bottleneckt precies daar zitten in de LAMP stach. Zoals Rasmus (uitvinder PHP, hotemotoot bij Yahoo) al ooit zei: gewoon een extra server inprikken en klaar. Wat niet wegneemt dat onhandige ontwerpfouten de zaken onnodig kunnen vertragen (lees: Hyves). Drupal draait sites met miljoenen gebruikers (bedenk: dat is het aantal inwonders van een klein land!) op drie of vier servertjes. In de practijk (en in theorie) blijkt de grootte niks uit te maken. Dei "ongeschiktheid" waar Carl het over heeft gaat vooral om het kunnen ontwikkelen op DRupal. En ik ken hem en weet dat hij dat in ieder geval niet kan. Gelukkig zijn er meer dan genoeg competente mensen die Drupal wel inzetten voor Corporate projecten.

Bart Feenstra zei

Ik ben het zowel met jou als met hem eens, Bèr. Ik weet niet van alles waar het over gaat iets af, dus ik beperk me tot de dingen waar ik wél over mee kan praten.

Conditional includes: Wat hij beweert is dat het gebruikt is om de overhead aan te pakken, maar dat developers van contributions te lui zijn om het te implementeren. Hij heeft gelijk dat het bedoeld is voor de overhead, maar hij gebruikt er zo'n negatieve toon bij; dezelfde die hij gebruikt over het cachen. Om het even met auto's te vergelijken: Hij vindt een auto pas goed als er een krachtige en zuinige motor in zit. Dat het ontwerp wat gestroomlijnder is gemaakt voor nóg minder brandstofverbruik betekens volgens hem dat de techniek in de auto dus niet goed is. Ik zie het echter als een extra verbetering.

Ook over caching loopt hij te klagen. Ik vind het zelf erg handig, want je ontkomt er niet aan dat je voor requests dingen moet berekenen en renderen, hoe efficiënt je systeem ook mag zijn. Net zoals conditional includes biedt caching dan een extra laagje performancewinst. Hij zegt ook dat deze feature slecht is voor real-time data. Hier blijkt inderdaad zijn onkunde uit, want dingen hoeven niet gecached te worden.

Ik vraag me af in hoeverre je core code mag/moet overriden, een feature die hij - blijkbaar - erg graag ziet. Het nadeel aan core code overriden is dat je zomaar de hele werking kan veranderen en daar moet je erg voorzichtig mee zijn. Toegegeven, het kan soms erg handig zijn, maar persoonlijk vind ik het niet iets waar je zo luchtig over moet doen.

Als laatste wil ik nog even bevestigen dat ik hem ook een gigantische zeurpiet vind. Je mag best alleen de negatieve kanten benadrukken, maar zorg er dan wel voor dat je je - zoals ook al eerder gezegd - oriënteert. Ook het gezeur over verschillende databases... Hij had op z'n minst kunnen vertellen dat er op dit moment hard aan gewerkt wordt en dat in de huidige versie van de Drupal 7 database layer ondersteuning voor meerdere databases zit.

Over databases gesproken, Bèr, Drupal kan voor zover ik weet alleen MySQL en PGSQL aan, geen andere types.

Ik ben zelf redelijk van van het principe "eerst de bestaande dingen goed uitwerken, dan pas nieuwe dingen erin stoppen (en die dan het liefst ook gelijk goed uitwerken)" en dat mis ik soms een beetje bij Drupal. Denk aan multilanguage support bij Drupal 6. Content translation is erg lekker gedaan, maar veel andere dingen kunnen weer níet vertaald worden. Ik snap dan niet waarom ze begin dit jaar Drupal 6 überhaubt gereleased hebben, aangezien deze feature dus niet goed uitgewerkt was.

Ik ben geen die-hard PHP developer en ik heb me ook nauwelijks in de Drupal core verdiept, dus ik kan over de rest niks zeggen. Mijn gezeur houdt hier dus eventjes op :)

Anoniem zei
Deze reactie is verwijderd door een blogbeheerder.