[fria24] Vilken teknik bör användas ?

Dario Lopez-Kästen dario at ita.chalmers.se
Fre Okt 28 06:39:56 CEST 2005


Disclaimer:

* jag är zope-utvecklare, jag gillar python skarpt, och jag får lön för 
att utveckla saker i Zope/Python.

* jag respekterar men föredrar inte PHP, överhuvudtaget, jag gillar inte 
sid-centrerade utvecklingsmodeller och jag ser inte att denna sorts 
utveckling kan var hållbar för framtiden - tvärtom ser jag att all 
utveckling av större och omfattande www-system, allt mer rör sig mot 
gammal, hederlig applikations utvekcling - AJAX och liknande teknologier 
är ett tecken på detta.

* Jag vill framför allt inte starta ett old-styöe plattformskrig, men 
jag vill bemöta litet av den FUD mot Zope/python som jag upplever finns 
i detta brev.

* Jag vill helst att man utvekclar ngt som är plattformsagnostiskt - där 
man har protokoll som skall följas och inte låser sig i lo-fi teknikval, 
och att de system och delsystem man bygger skall kunna prata med varandra.


Anders Wallenquist wrote:

>Det är en kostnadsfråga också, Zope och JBoss är på många sätt bra
>verktyg men de är dyra
> i deployment i jämförelse med exempelvis vanlig hederlig LAMP.
>  
>
<..snip..>

>Vartenda webbhotell erbjuder LAMP, men det är tunnsått med Zope och
>JBoss. En stor myndighet med gott om pengar har inga problem att införa
>Zope och säkert göra fantastiska saker med Zope, men den lilla kommunen
>har inte en chans. Det är inte helt självklart att JBoss eller Zope
>vinner en TCO-jämförelse med t ex DotNet - kanske mot J2EE på Sun, men
>DotNet på billig Intel-plattform kan vara tufft. SugarCRM som är LAMP
>finns redan på programverket.org, P som i PHP.
>
>Har erfarenhet av kommuner och offentliga system, både stora och små.
>Min rekommendation är att välja en plattform som även kan fungera hos de
>mindre, men skalbar för lite tuffare sammanhang.
>  
>

eh... jag ingår i ett team som driftar typ STORA Zope system (med 
personaliserade sidor för typ 100-200 samtidiga användare) och jag 
känner inte igen mig i vad du beskriver, alls. Zope är billigt att 
driftsätta i jämfört med många andra system, det handlar bara om att 
göra rätt saker och det r inte så svårt att göra rätt saker.

Man får ju jämföra på rätt sätt också. En anledning till att inte så 
många erbjuder JBoss och Zope är att de inte är "enkla", om man kan 
kalla dem så, CGI-aktiga system, utan de har egna request brokers, 
persistens-maskinerier, osv. Det handlar alltså inte om bara "parsa 
denna sidan" utan det handlar om kompletta system. Båda dessa klara sig 
utan en apache i frontend.

En intressant fördel med Zope är att den kommer Kluster-ready Out of the 
box. Det är den enklaste sak i världen att starta ett kluster med X 
noder och en back-end - detta ingår i standard zope-distributionen. Det 
fungerar - vi anvädner det hela tiden.

Vill man ha redundant backend, så finns det möjligheter till det också. 
en fir potentiell lösning och en fungerande, i produktion använd 
icke-frilösning.

Enda gången det blir komplicerat med Zope är när man skall modellera 
HA-lösningar efter LAMP-princpen - detta behövs inte alls, och fungerar 
ofta dåligt med Zope, då blir det dyrt.

Det zope-kräver är mycket minne i maskinerna, men den kräver inte 
superhårdvara, och den kräver CPU-affinity på multicpu hårvara - det är 
de enda speciella grejerna som jag könner till om zope.

>Jag lägger min röst på Drupal.org, det är en LAMP-lösning, bra och enkel
>att utveckla i, kan driftas av en liten organisation utan erfarenhet av
>Linux tidigare, går utmärkt att konfigurera med enbart
>fria program på t ex Debian/Ubuntu-plattform. Det finns fina
>SOA/Webservices-kopplingar, klarar ordentlig last, går att
>lastbalansera, E-handel, CRM, CMS med vattentäta skott mellan innehåll
>och tema-motor, riktig begreppsapparatmotor med synonymhantering,
>Ajax-stöd för feta klienter - är på alfa-stadium, men kul att ha när det
>kan vara tillräckligt stabilt för professionella lösningar. Lätt att
>hitta utvecklare till, bra översättningssystem, stor internationell
>användarförening med bra fart på utvecklingen.
>
>Drupal kan levereras av många av de mindre konsultbolagen knutna till
>Linux-föreningen. JBoss kräver certifiering och stora investeringar för
>att kunna bli leverantör av, Zope har jag jagat utvecklare
>till i Sverige och det finns inte många...
>  
>

Det finns fler stycken, fler än vad man tror, och det finns också bolag 
som arbetar med zope/python. Dock finns det inte lika många som 
php-utvecklare.

>Att ingen vill utveckla servrar i PHP håller jag inte med om, det finns
>flera stycken inom ramen för Drupal och Pear. Skulle jag skriva en
>server från scratch kanske jag hellre skulle välja Perl eller C++, men
>borde inte vara några större problem att blanda Perl och PHP på en
>LAMP-plattform. Värre att blanda Zope med PHP, Perl eller Java.
>  
>

Zope går alldels utmärkt att blanda med PHP och java, och om man går SOA 
vägen så borde det inte vara några problem vad man bygger det i.

>Ubuntu innebär att en kommun kan få samma underhållsavtal som Red Hat
>Enterprise bas utan kostnad i 18 eller 60 månader. Drupal är på inget
>sätt hårt knutet till Debian eller Ubuntu, men lösningen kommer jämföras
>med real-life konkurrenter i alla aspekter och det gäller att skaffa så
>många argument som möjligt. Att kunna välja en i verkligt mening helt
>fri plattform borde vara en poäng det också.
>  
>

Inget ont om Drupal, jag har rekommenderat det själv till ett ställe, 
men jag är tveksam till att bygga infrastruktur i PHP; i ett sådant fall 
skulle jag rekommendera Perl, eller *brr* Java (som jag inte heller 
gillar ;-).

Nog, med plattformskrig, jag har en fråga om en grej som jag inte fått 
riktigt grepp om:

* Vad är fokus på detta projekt?

- Att tillhandahålla "ut mot användaren-lösningar"

eller

- Att tillhandahålla lösningar som hanterar hela 24-timmars 
problematiken, där "ut mot användaren-lösningar" är en del av det stora 
hela.

Hittills har vi diskuterat vad vi skall ha för teknik för de 
www-baserade lösnignarna som skall finna ut mot anvöndare, men det finns 
ganska mycket att göra innan man kommit så långt, inte minst att 
gränssnitta mot existerande system.

Mina 2 ören.

/dario

-- 
-- -------------------------------------------------------------------
Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
Lyrics applied to programming & application design:
"emancipate yourself from mental slavery" - redemption song, b. marley





More information about the selinux-fria24 mailing list