Clusterfuck

Ursäkta titeln (som faktiskt inte är snuskig, se http://www.urbandictionary.com/define.php?term=clusterfuck).

Det jag ska negga om idag är klustring. Möjligen går det ett sus i utvecklarleden när jag skriver detta (nåja, ett sus bland de typ 12 ynka själar som hittat hit).

Klustring är väl det vedertagna sättet att säkra skalbarhet?
Dissa inte klustring, len!

(eftersom jag redan börjat länka till ordlistesajter och din förortssvenska kanske är lika skral som min: http://sv.wikipedia.org/wiki/F%C3%B6rortssvensk_ordlista)

Alla har vi väl hört någon på tekniksidan säga (eller i värsta fall sagt själva) på ett möte där business case-killarna skissar på scenarier med 25000 samtidiga användare:
"Det är lugnt, vi klustrar lösningen och adderar bara noder för att skala. Vår applikationsserver stöder klustring och databasen med"

Det är här vi går på samma mina som management gör när grabbarna från Rational (se http://hellrefaraherde.blogspot.com/2007/11/uml-underliggande-megakomplext-elnde.html)

kommer och säljer in metodik och svindyra verktyg: Vi hugger på silver-bullet-wobblern som en vårpilsk gädda!

Vad gäller management så får de ett paket med verktyg och rigida dokumenteringsregler som ger en illusion av ordning och reda, effektiv utvecklingsprocess och ROI (påminn mig förresten att jag ska skalla alla som säger ROI i tid och otid - 'När kan vi få ROI på den här fitchjurn?')

Utvecklarna får en illusion av en lans med vilken den mest skrämmande av alla bestar - prestandaproblemen - kan dräpas.

Missförstå mig rätt - jag anser såklart inte att man ska ha en dunderburk till server som gör allt - självklart behövs lastdelning mellan maskiner med olika ansvarsområden och möjlighet att addera fler burkar när det behövs (och om det hjälper).

Skillnaden är då att man får en 'klustring' som är skräddarsydd för ditt system - en fast nyckel istället för en skiftnyckel (och som alla som testat vet, så spöar den fasta nyckeln skiftnyckeln every time)

Eller för att dra till med en annan liknelse - hur sugen är du på att köpa ett par unisex-byxor i one-size-fits-all-stretch? Låter inte optimalt...

Skiftnyckeln/byxorna i det här exemplet är din applikationsservers/databas/messaging engine eller whatever's inbyggda lösning för att klustra upp systemet i brygga. Den har säkert som fjäll i Feskekörka:

• Kommit till främst för att tillfredsställa säljarna på produktföretagen som måste erbjuda klustring eftersom konkurrenterna har det
  
• Blivit så generell att den inte löser något specifikt problem (dvs t ex ditt systems) bra
  
• Blivit feature-bloated med distribuerade cachar, hot node deploying och fan och hans moster - inte ett öga torrt
  
• Pga feature-bloatningen blivit helt omöjlig att konfigurera för en vanlig dödlig - specialkonsulter måste tas in för att vada i träsket med XML-config-filer
  

Ovanstående information och t ex en brasklapp om att inte alla system passar för att klustra med just applikationsserver X:s inbyggda klustringsstöd står ingenstans att finna.

T o m mysql har skitnödigt lagt till klustringsstöd som ingenstans marknadsförs som nåt annat än det bästa sen skivat bröd.

Vi gjorde ett testskott med ett mysql-kluster i ett projekt jag jobbade i förut.
Första setup (innan klustring):

• Två servrar, en master och en replika som select-nod. Vi normaliserar prestanda på denna setup till 100%
• Andra setup (med klustring):
  Fyra servrar (minimalt mysql-kluster), samma applikation - Prestanda: 50%

Vi får en skalbarhetsfaktor på 4! Fast vänta... Åt fel håll. Hälften så snabbt med dubbelt så mycket hårdvara.

Hittade sen äntligen nåt obskyrt dokument på nätet som faktiskt erkände att mysql-klustring ställer en hel del krav på applikationens karaktär för att rocka. T ex gillar den inte joins så mycket. Då blir overheaden när servrarna pratar med varann så stor att systemet knäar.

Så om din applikation aldrig joinar tabeller utan bara gör uppslagningar på primary keys (fat chance) så kan mysql-klustring få din Volkswagen att bli en Porsche.

Men, vadå? Klustring funkar ju för världens mest använda gigantokluster Google?
Japp, men det gör det precis just för att de byggde en speciallösning för deras specifika behov, ett distribuerat operativsystem byggt enbart för snabb sökning och skalbarhet.

Hade de valt att sjösätta i WebLogic (eller insert valfri applikationsserver här) och klustra med deras stöd (vilken absurd tanke!) så skulle nog en google-fråga ge svar efter ett par kvartal istället för millisekunder...

Följa John

Jag har varit så pass länge i systemutvecklingsbranschen att jag insett ett par saker.

• There is no silver bullet
• Om något pushas som det bästa sen sliced bread så är det nåt grundläggande fel nånstans
• Det är (faktiskt) inte alltid fel att uppfinna hjulet igen (eller kanske inte hjulet, men kanske chassit, karossen och inredningen för att fortsätta på den något krystade bil-liknelsen)
  

Låt mig ta några exempel. Jag tillhör, måste jag erkänna, dem som svalde krok, lina och fiskespö när J2EE-tåget lanserades med buller och bång på senare delen av 90-talet.
Här kom en spec, en standard som skulle lösa alla mina problem - persistens, distribuerade lösningar, messaging och en hel massa annat. Sun, i sin oändliga vishet, publicerade en "show case"-app i form av "pet store" full av
J2EE-patterns att använda för intet ont anande utvecklare världen över.
Inte nog med det - "Enterprise" i namnet gjorde att management i tusentals företag också svalde betet. Att använda J2EE blev ett slags kvalitetsstämpel; en garant för att lösningen var byggd på solid grund, lätt att underhålla och skala upp.

Hej vad vi alla bedrog oss. Om man bara hade använt sin (iofs på den tiden betydligt kortare) erfarenhet och utbildning och verkligen läst specen istället för att kasta sig över ett kodexempel och med ett fånigt flin på läpparna sjösätta sin första Entity Bean i nån mer än lovligt buggig och seg 'container'.

Vad som framgår som pinsamt tydligt nu i ett förklarat ljus är att J2EE-specen var ett typiskt 'Design by Commitee' piece of crap. En kopp komplexitet tillsammans med fyra liter configuration i form av XML och sex matskedar magi - vad containern har för sig under huven visste man inte riktigt (och det var ju inte meningen att man skulle behöva veta det heller). Lycka till förresten med att sätta en debug-stopp långt inne i JBoss mitt i nån ConfigurationFactoryManagerFactory eller nåt som är i full färd med att instansiera sig själv utifrån nån vidrig XML-blobba.

Applikationerna blev precis det motsatta mot vad som utlovades:

• Skalbarhet - my ass. Nåt segare än en J2EE-applikation med Entity Beans går inte att uppbringa. Det är datavärldens motsvarighet till en bil med prestanda från en Trabant och komplexitet hos en Ferrari F1
• Maintainability - tanken var att eftersom allt var byggt efter en enhetlig spec skulle man kunna byta utvecklare i ett projekt lika ofta som man byter kalsonger. Vem som helst skulle kunna kliva in och vara produktiv på en gång. Detta föll genast eftersom alla var tvungna att kringgå den vidriga specen med hembyggda lösningar (som ofta blev mer eller mindre de facto patterns för J2EE-utveckling) som t ex "fast lane" (dvs gå direkt med JDBC mot databasen för att göra saker som inte gick att göra med J2EE (som att läsa upp fler än 10 objekt t ex (hmm, ett persistensramverk som inte fixar att läsa upp ett tjog objekt eller så från databasen borde ju fått folk att tänka efter)))
• En tredjeparts-marknad med färdiga komponenter färdiga att bara drag-and-droppa in i din container och vips så funkar allt! Att bygga ett system skulle bara kräva en systemdesigner (gärna i kostym) som i samråd med beställaren grafiskt drar-och-släpper komponenter i en grafisk högnivå-utvecklingsmiljö. En luttrad utvecklare inser kanske att det är omöjligt att t ex komma fram till en generell definition av ett så basalt begrepp som 'användare'. Vissa system behöver user name och mail address, medan andra behöver längd i cm och hårfärg. Marknaden för tredjepartskomponenter blir snabbt begränsad till komponenter för typisk generell funktionalitet - mail-skickning, och messaging t ex

De enda som drar nytta av eländet är företag som säljer J2EE-containers och de som konsultar i ämnet. Mest de som gör bådadera, t ex säljer en vidrigt komplex container (läs WebLogic) och sen säljer vidrigt dyra konsulttimmar för att röja upp i de katastrofprojekt som (naturligt nog) inte kan leverera utifrån en galen spec (läs J2EE) implementerad i en överkomplex container (läs WebLogic). Där har ni en bra affärsidé. Synd att det inte var jag som kom på det.

J2EE är en typisk 80-20 deal. Det går bra att utveckla 80 procent av din applikation (om du kan stå ut med att den är seeeeg), medans resterande 20 procent är omöjlig att utveckla eller måste byggas i strid med vett och sunt förnuft för att kringgå alla hinder som J2EE lägger i vägen.