Kolmikerrosarkkitehtuuri on yksinkertaisesti todella hieno ja käyttökelpoinen. Miltä muulta arkkitehtuurimallilta onnistuu kaikki seuraava?

Absent from the list of contributors to TOSCA are Amazon and Microsoft. “They were invited,” said Ferris. “We welcome any other companies to come. We feel that [...]]]> InfoWorld kirjoitti lyhyesti OASIS-ryhmän TOSCA-määrittelystä, kuvauskielestä pilvijärjestelmien provisiointia ja orkestrointia varten. Mitä se sitten onkaan. TOSCA ei tässä minua kiinnosta, vaan tämä toteamus artikkelissa:

Absent from the list of contributors to TOSCA are Amazon and Microsoft. “They were invited,” said Ferris. “We welcome any other companies to come. We feel that we have a fairly good constituency involved.”

Amazon Web Services (AWS) ei halunnut osallistua pilvistandardointiin. Tämä ei ole mikään uusi asia – AWS ei ole aiemmin korvaansa lotkauttanutkaan DMTF:n (Distributed Management Task Force) OVF-hankkeeseen tai SNAI:n (Storage Networking Industry Association) CDMI-pilvidatahankkeelle.

Miksi ei?

Siitä ei ole mitään hyötyä Amazonille. Pikemminkin päinvastoin. Oma arvioni on, että Amazon lähtee pilviteknologian ja sen rajapintojen standardointiin vain jos joku pystyy uhkaamaan sen kaupallista ja brändiylivoimaa pilvimarkkinoilla.

Amazon on dominantti toimija pilvimarkkinoilla. Dominantin pelurin valinnoista muodostuu usein de facto -standardeja kun muut alkavat toteuttaa dominantin teknologian kanssa yhteensopivia ratkaisuja. Näin on käynyt esimerkiksi IBM:lle useasti niin höyrykoneaikaan kuin PC-tietokoneiden kanssa.

Jos yritys ei kuitenkaan halua hännystellä markkinajohtajaa, pitää sen tehdä jotain muuta. Usean pienemmän kilpailijan omiin ratkaisuihin nojaaminen kuitenkin ennemmin ohjaa ostajia markkinajohtajan syliin – jos kaupan hyllyllä 70% on VHS-nauhureita ja loput kolmea eri kilpailevaa epäyhteensopivaa ratkaisua, niin minkä ostaisit? Standardointi onkin tapa yhdistää fragmentoitunut markkina standardin taakse ja saada mahdollisuus haastaa markkinajohtajan teknologia.

Ja tästä syystä markkinajohtajan ei kannata lähteä standardointiin mukaan. Olisi hölmöä sitoa omat kädet eli sekä rajoittaa oman tuotekehityksen innovointia, että vähentää oman alustansa lock-in-efektiä.

Kun markkinajohtaja menettää kärkisijansa, kannattaa sen osallistua standardointiin. Joskus entinen markkinajohtaja ei tajua tilanteen muuttumista ja yrittää toimia edelleen kuten olisi herra talossa. Esimerkiksi tästä kelpaa IBM:n MCA-väyläratkaisu, joka ei lopulta kiinnostanut oikeastaan ketään. Saattaa olla toki, että Amazon yllättää ja syleileekin avoimia standardeja ennen kuin on ihan pakko. Historian valossa en kuitenkaan pidättäisi hengitystäni.

We’ve got some cool and interesting news to share. Please join us at our live online event on Jan. 18th at 9am PST to learn more about the next big thing in the AWS cloud.

Ei etteikö DynamoDB olisi kiinnostava, mutta hei [...]]]> AWS julkisti viime viikolla DynamoDB:n, jota puffattiin etukäteen vähän salaperäisellä kutsulla:

We’ve got some cool and interesting news to share. Please join us at our live online event on Jan. 18th at 9am PST to learn more about the next big thing in the AWS cloud.

Ei etteikö DynamoDB olisi kiinnostava, mutta hei haloo – ei se nyt minusta oikeasti ole niin radikaali. Tuliko Amazonille kiire, kun suuri osa asiakkaista ohitti SimpleDB:n ja käytti ennemmin Cassandraa skaalaamiseen?

Vähemmälle huomiolle on sensijaan jäänyt pari DynamoDB:n jälkeen tehtyä julkistusta jotka ovat kuitenkin mielestäni erityisesti suuryritysten pilvipalveluiden käytön kannalta merkittäviä:

• http://aws.amazon.com/about-aws/whats-new/2012/01/19/Announcing-IAM-Identity-Federation-To-AWS-Management-Console/ – Pääsy AWS-konsolille voidaan tehdä federoidusti, eli esim. yrityksen olemassaolevan AD-käyttäjäkannan kautta (ei tosin ihan helposti, integrointi on vielä lapsenkengissään – mutta eiköhän se parane nopeasti).
• http://aws.amazon.com/about-aws/whats-new/2012/01/24/amazon-rds-announces-support-for-vpc/ – RDS-instansseja pystyy nyt luomaan VPC:n eli ”oman yksityisen julkisen pilven” sisälle. Tämä puute on saanut monilta WTF-kommentteja kun aiemmin olen kertonut siitä. Ei enää.
• http://aws.amazon.com/about-aws/whats-new/2012/01/24/announcing-aws-storage-gateway/ – Amazonilta uusi veto – kaupallinen ($125/kk) softa, joka viedään asiakkaan levyjärjestelmiin kiinni. Ja se liittää olemassaolevan levyinfran S3:een.

Viimeisestä en usko näkeväni vielä koko kuvaa. Vatsassa on jotenkin sellainen kutina, että kyseessä on uudenlaisen suuryritysten datakeskusten valtaamisstrategian ensimmäinen askel. Sille lienee jatkoa luvassa.

Eivät sittenkään. Osassa on mietitty vähän hämärämpiä käyttötapauksia, ja mahdollistettu muun muassa osittaisen matchin erottaminen epäonnistuneesta matchista. Kaikkein yleisikäyttöisin rajapinta olisi sellainen, joka mahdollistaisi täyden streamauksen, mutta se on harvinainen.

Otetaan esimerkki käyttötapauksesta: webissä on sivu, ja sivulla lomake, jossa on kenttiä, joilla on jotain muotovaatimuksia. Kehittäjä määrittelee [...]]]> Regexp-kirjastot ovat funktionaalisesti kaikki samanlaisia. Vai ovatko?

Eivät sittenkään. Osassa on mietitty vähän hämärämpiä käyttötapauksia, ja mahdollistettu muun muassa osittaisen matchin erottaminen epäonnistuneesta matchista. Kaikkein yleisikäyttöisin rajapinta olisi sellainen, joka mahdollistaisi täyden streamauksen, mutta se on harvinainen.

Otetaan esimerkki käyttötapauksesta: webissä on sivu, ja sivulla lomake, jossa on kenttiä, joilla on jotain muotovaatimuksia. Kehittäjä määrittelee muotovaatimuksen regexpillä. Halutaan dynaamisesti päivittyvä feedback, joka osaa kertoa, ei pelkästään onko kenttään kirjoitettu data kelvollista tai kelvotonta, vaan myös että voisiko se olla kelvollista, jos siihen lisättäisiin vielä jotain. Näin esim. luottokorttinumero olisi kesken kirjoittamisensa tilassa “ei vielä ok, mutta jos kirjoitat lisää, voisi olla ok”.

Tämän toteuttaminen pelkällä regexpin match-metodilla on hieman hankalaa. Aidoille regexpeille voidaan toteuttaa automaattinen transformaatio, joka muuttaa yhden regexpin toiseksi, joka matchaa kaikkiin ensimmäisen valideihin prefikseihin. Jos regexpejä laajennetaan epäaidoiksi sallimalla back referencet, tämä strategia ei enää edes toimi.

PCRE:ssä (C-kirjasto) erottelu saadaan aikaan antamassa pcre_exec:ille flageissa PRCE_PARTIAL_HARD, ja tunnistamalla paluuarvona PCRE_ERROR_PARTIAL (vastakohtana PCRE_ERROR_NOMATCH:ille). (Englanninkielinen termi on partial match.)

Muita tutkiessa vastaan tulleita kirjastoja, joissa tämä onnistuu, on Boost (C++) ja JRegex (Java). Boostia voi pitää jossain määrin standardina C++-ympyröissä. Javassa useimmat ammatinharjoittajat käyttävät standardikirjaston regexpejä, eikä tule mieleenkään, että parempikin ratkaisu (ja kyllä, JRegex on monilla tavoin parempi) on olemassa.

Pythonin standardikirjasto ei tätä tue, eikä laajennustakaan löydetty. Samoin kävi Javascriptin tapauksessa.

Oikeastaan ainoa asia, joka jäi enemmän häiritsemään, oli Javascript. Alkuperäinen käyttötapaushan haluttaisiin tietysti toteuttaa Javascriptillä, koska kyseessä on selaimessa tehtävä tarkistus.

Jos tarinassa on mitään varsinaista opetusta, se on se, että sen jälkeen, kun joku ominaisuus on saavuttanut kielen standardikirjaston, viat, jotka siihen ovat jääneet, ovat ikuisia. Vaikka ne korjattaisiinkin laajennukseen, suurin osa kehittäjistä käyttää standardikirjastoa. Tämä ei tietenkään koske suoranaisia bugeja toteutuksessa, koska ne on helppo korjata, vaan tällaisia korkeamman tason ajatusvirheitä siitä, mikä on mahdollisten käyttötapausten kenttä.

Niin, se täysi streamaus: kuvitellaan tilanne, jossa matchattava sisältö on pitkää, syöte tulee streamista ja tulos menee streamiin. Tällöin olisi hyötyä regexp-matcherista, jolle syöte voidaan antaa mielivaltainen pala kerrallaan, ja joka aina palan jälkeen osaa sanoa, missä tilassa on. Nämä tilat ovat no match, match ja ei voida tietää vielä, eli osittainen match.

Yleiskäyttöisiä palikoita suunnitellessa on aina ristivetoa streamattavien rajapintojen laajemman käytettävyyden ja kerralla asiat tekevien rajapintojen implementoinnin helppouden välillä. Aina oikeaa valintaa ei ole.

Itse olen käyttänyt pääosin EBS-instansseja jo pidemmän aikaa. Syyt löytyvät Ericin listasta numeroilla 1, 2 ja 6. Omassa käytössäni tärkeää on se, että EBS-instanssin levykuva säilyy raudan vikatilanteissa, instanssia voi sammuttaa ja käynnistää [...]]]> Eric Hammond perusteli loistavan hyvin ja kattavasti syyt sille, miksi AWS:ssä tulisi oletusarvoisesti käyttää EBS-instansseja ja -levyjä ns. ephemeral-instanssien sijaan.

Itse olen käyttänyt pääosin EBS-instansseja jo pidemmän aikaa. Syyt löytyvät Ericin listasta numeroilla 1, 2 ja 6. Omassa käytössäni tärkeää on se, että EBS-instanssin levykuva säilyy raudan vikatilanteissa, instanssia voi sammuttaa ja käynnistää mielin määrin, sekä mahdollisuus vaihtaa instanssia pienemmäksi tai isommaksi säilyttäen itse instanssin datan (ja käyttöjärjestelmän).

Eric ei kuitenkaan maininnut EBS-levyjen snapshoteista. Niin isojen kuin pienien päivitysten kanssa snapshotit  ovat kullanarvoisia – ennen päivitystä otat snapshotin ja jos jokin meni katastrofaalisesti päin metsää, palautat aiemman snapshotin. Tai vielä parempaa, otat uudet snapshotit vikatilanteesta ennen palautusta ja rupeat tutkimaan snapshotteja ilman mitään kiirettä. Snapshoteista voi tehdä uudet EBS-levykuvat, jotka voi vaikka liittää toiseen koneeseen ja penkoa sitä kautta vikaantuneen koneen levyjärjestelmää.

Oleellinen ero ephemeral-levyjä ja EBS-levyjä käyttävissä instansseissa on virtuaalikoneiden levyn elinkaari. EBS-instanssilla se on analoginen perinteiseen palvelinprovisiointiin: hankit koneen jossa on levyä, ja levy säilyttää datansa niin kauan kuin konetta ei heitetä roskiin. Datan säilymiseen ei vaikuta se onko koneessa tai edes koko talossa sähköä vai ei. AWS:ssä “sammutettu” EBS-instanssi ei kuluta prosessoria josta ei myöskään kuluja. Sammutettu EBS-instanssi ei ole täysin ilmainen, sillä sen levyvarauksesta pitää edelleen maksaa. Levykuvan koosta sitten riippuu onko tämä paljon vai vähän – 8 gigan levykuvan säilyttäminen “kylmänä” maksaa kuitenkin alle $1 per kuukausi.

EBS-instanssin levykuva hävitetään vasta kun kone heitetään “roskiin”, eli se deprovisioidaan – AWS:n termi tähän on “instance termination”. AWS:ssä on EBS-koneille mahdollista asettaa päälle “termination protection” ominaisuus, jolloin instanssin terminointi vahingossa muuttuu käytännössä mahdottomaksi.

Ephemeral-levyä käyttävät instanssin levykuvan elinkaari on toisenlainen. Se on sataprosenttisesti sidottu instanssin ajossa olemiseen. Analogiana voisi toimia ehkä mennävuosien RAM-levyt. Ephemeral-instanssien levyissä säilyy tieto vain niin kauan kuin sähköt ovat päällä. Sähköt pois? Zzzzup! Sinne meni data.

Ephemeral-instansseille on käyttötapauksensa. Jos kuitenkin aloittelet AWS:n käyttöä, et todennäköisesti törmää näihin käyttötapauksiin kovinkaan pian. Ilman parempaa syytä kannattaa valita EBS-instanssi. EBS-instanssin käyttömalli on lähempänä perinteistä palvelinprovisiointia joten siitä tulee vähemmän yllätyksiää.

(Antille: Yksi käyttötapaus on tosiaan juuri se Hadoop-klusteri, jossa EBS-instansseista ei ole oikeastaan mitään hyötyä. Ellei sitten halua ajaa t1.micro-klusteria.)

Väärän työkalun käytöllä on seurauksensa, joskus työkalulle ja joskus sen käyttäjälle.

“Ja tästä kuuluu teille ehdottomasti kiitos. Haastattelunne oli suorin (ja tiukin) missä muistan koskaan olleeni. Ennenkaikkea kiitän teitä konsulttitoimen rehellisestä läpikäynnistä. Tämän ansiosta pääsin siihen lopputulokseen, ettei minusta ole konsultin työhön.”

Itsensä ymmärtäminen on erittäin tärkeää ja muiden auttamisesta tulee mukava lämmin [...]]]> Kuulin rekrykandidaatilta miten hän piti työhaastatteluamme hyödyllisenä kokemuksena. Alla lainaus sähköpostista:

“Ja tästä kuuluu teille ehdottomasti kiitos. Haastattelunne oli suorin (ja tiukin) missä muistan koskaan olleeni. Ennenkaikkea kiitän teitä konsulttitoimen rehellisestä läpikäynnistä. Tämän ansiosta pääsin siihen lopputulokseen, ettei minusta ole konsultin työhön.”

Itsensä ymmärtäminen on erittäin tärkeää ja muiden auttamisesta tulee mukava lämmin tunne. Mmmm. Vaikka sitten jäimmekin vaille pätevää henkilöä tällä kertaa.

Mitä kuitenkin on se konsultin työ, joka ei kaikille loppujen lopuksi ole sopivaa? Konsultointia on monenlaista – karkeasti sen mitä “konsultoinniksi” kutsutaan voi jakaa resurssivuokraukseen, asiantuntijatyöhön sekä ns. “oikeaan” liikkeenjohdon konsultointiin. Kaikkia näitä kuitenkin yhdistää muutama teema jotka ovat kaikenlaiselle ohjelmistoalan ulkoistetulle työlle yhteisiä:

1. Työn jatkuvuudesta ei ole takeita
2. Alihankkijoita ei julkisesti kiitellä
3. Konsultin kympin suoritus on oikeasti vain ysi
4. Työmatkat muuttuvat jatkuvasti

Nämä johtuvat konsultointityön luonteesta.

1  Yksi yleinen syy ulkoistuksen käyttöön on yritysten helpompi mukautuminen työvoimatarpeen vaihteluihin. Siis helpompi tilaajan, ei toimittajan näkökulmasta katsottuna. Ergo, konsulttien miehittämät projekti on helpompi lopettaa. Resurssivajetta paikannut konsultti lähtee kun vaje paikataan.

Yli puolen vuoden konsulttikeikat ovat pitkiä. Useiden vuosien keikkoja on kyllä olemassa, mutta niistä ei koskaan etukäteen tiedä. Konsultin on hankala ennakoida sitä mille asiakkaalle hän seuraavassa kuussa tekee töitä.

2  Ulkoistuskumppaneille ei satele julkisia kiitoksia. Monessako lehtihaastattelussa olet nähnyt jonkin firman kiittelevän alihankkijoidensa panosta omasta menestyksestään? Et yhdessäkään. (No, en ole tehnyt tästä tarkkaa tutkimusta. Ehkä yhdessä siis.) Tuskin kukaan hakeutuu softa-alalle julkisuudenkipeyttään, mutta jos kuitenkin silmissäsi vilkkuvat jutut kasvuyritysten menestyksestä, niin mene toki sellaiseen, mutta älä konsulttina.

En tarkoita etteikö asiakkailta tulisi positiivista palautetta. Hyvä työ kyllä tunnustetaan. Ulkoistetun henkilöstön rooliin kuuluu kuitenkin pysyä taka-alalla ja antaa yrityksen oman henkilökunnan paistatella menestyksen tuomassa huomiossa.

3  Hyvän konsultin tuntihinta on merkittävästi suurempi kuin vakityöntekijän tuntipalkka. Vaikka konsultti ei välttämättä itse saa koko laskutuksestaan itse palkkana kuin (murto-)osan, vakityöntekijän näkökulmasta konsultti on (karrikoiden) a) ulkopuolinen tunkeilija joka saa b) samasta työstä törkeästi parempaa liksaa. Käytännön seuraus tästä on se, että konsultin ja vakihenkilöstön työsuorituksia mitataan erilaisella mitta-asteikolla. Korkea hinta tarkoittaa parempaa tulosta, eikö niin?

Tämä kuulostaa aika raa’alta. En tarkoita, että konsultit olisivat kakkosluokan kansalaisia. Mutta konsultin on oltava aina “vähän parempi” ollakseen yhtä hyvä kuin muut. Jos tavoittelet kympin suoritusta, sinun pitää vääntää nuppi yhteentoista. Jos haluat ysin, pitää tehdä kymppi. Ja jos teet keskinkertaisen eli seiskan, se on oikeasti huono eli kutonen.

4  Asiakkaiden ja projektien vaihtuessa myös konsultin pitää ottaa jalat alleen ja liikkua. Mitä korkeampaa “jalostusastetta” konsultti on, sitä enemmän matkallisesti kauas vieviä reissuja on luvassa. Lopullisen työpisteen sijaintiin ja sen vaihtuvuuteen vaikuttaa niin konsulttifirman asiakaskunta kuin konsultin tarkka työnkuva, mutta yhtä lailla, työmatkat vaihtuvat usein.

Tämä pätee myös rajoitetulla maantieteellisellä alueella toimiville – PK-seudulla yksi asiakas voi olla Otaniemessä, seuraava Vantaalla ja kolmas Helsingin ydinkeskustassa. Lyhyt työmatka on toki aina kiva yllätys, mutta yleensä vain hetkellinen etu.

…

Ei tämä pahaa ole. Se vain poikkeaa siitä, mitä pidetään “normaalina” työnä.

Ohjelmistoalan konsultointi tarjoaa loistavan tilaisuuden nähdä tiivistetysti paljon erilaisia työympäristöjä, ihmisiä, tapoja toimia, erilaisia asiakkaita ja projekteja. Omaa osaamistaan toistuvasti pinnistämällä kehittyy nopeasti. Jokainen asiakas toimii enemmän tai vähemmän omalla tavallaan ja ulkopuolisella konsultilla on mahdollisuus ottaa omaan työkalupakkiinsa eri työpaikkojen parhaat käytännöt.

Uskotko, että sinusta olisi konsultiksi? Lähetä CV ja vapaamuotoinen työhakemus osoitteeseen rekry[at]codento.com.

En aio rynnätä eturintamaan puolustamaan sanan “haaste” kunniaa. En, vaan ammun sitä selkään näppäimistöni takaa. Inhoan koko sanaa–tai oikeastaan sen väärinkäyttöä.

Elävät kielet ovat täynnä värikkäitä ilmaisuja, jotka ovat syntyneet ihmisten taisteluista maailmankaikkeutta [...]]]> Uuden vuoden aattona Arto Nyberg haukkui radiossa (kohdasta 11:11 eteenpäin) sanaa “haaste” sisäsiistiksi konsulttislangiksi, “joka ei kerro elämästä sen oikeita asioita.”

En aio rynnätä eturintamaan puolustamaan sanan “haaste” kunniaa. En, vaan ammun sitä selkään näppäimistöni takaa. Inhoan koko sanaa–tai oikeastaan sen väärinkäyttöä.

Elävät kielet ovat täynnä värikkäitä ilmaisuja, jotka ovat syntyneet ihmisten taisteluista maailmankaikkeutta vastaan. Palaverin sopiminen tusinan kiireisen päättäjän kanssa vaatii työtä ja aikaa; se on siis työlästä. Lähikaupan kylmäketju katkeaa usein; kyseessä on ongelma. Ulkomainen ulkoistuskumppani vastaa vain joka kolmanteen sähköpostiin ja siihenkin asian vierestä; kommunikaatio on hankalaa.

Haasteella on sanana paikkansa. Sen käyttäminen vihjaa, että yksilö tai yhteisö on päättänyt ryhtyä tarmokkaasti toimeen muuttamaan vallitsevia olosuhteita. Haaste on otettu vastaan. Usein lopputuloksena on jotain positiivista–henkilökohtaista kasvua, suurempi markkinaosuus ja niin edelleen.

Miten ylläolevat virkkeet sopivat tähän?

Palaverin ajan löytäminen on haastavaa. Kenelle? Kenen osaaminen kasvaa siitä, jos tämä haaste otetaan vastaan ja voitetaan?

Kylmäketjun ylläpidossa on ollut runsaasti haasteita. Miten vakavia? Onko kylmäketju katkennut vai onko sen ylläpito kallista? Sana haaste peittää tässä tärkeää informaatiota.

Lopuksi rajatapaus: Kommunikaatio on haastavaa. Tässä tapauksessa alkuperäisen lauseen sanan “hankala” käyttö piilottaa yksityiskohtia. Se kuitenkin paljastaa enemmän puhujan asenteesta kuin kevyesti heitetty “haastava.” Rivien väleistä voi lukea, että kommunikaation vaikeus on hyväksytty vallitsevaksi asiantilaksi. Jos puhuja on kuitenkin motivoitunut parantamaan yhteistyötä kumppanin kanssa, “haaste” saattaakin sopia tilanteeseen paremmin.

Taitava konsultti oppii asiakkaan käyttämän kielen ja kertoo oman viestinsä asiakkaan käyttämillä termeillä. Jos asiakkaalla on ongelma, konsulttikin kutsuu sitä ongelmaksi.

Ymmärrän hyvin “haasteen” houkutuksen. Miten kutkuttavaa onkaan ohjelmoida asiakas näkemään tilanteensa positiivisemmassa valossa! Tällaisessa interventiossa on samat vaarat kuin antibiooteissa; liiallinen käyttö johtaa resistenssiin. Hyvä sana muuttuu “konsulttipotaskaksi.” (Ja ah, toimiiko asioiden suora kertominen koskaan? Parempi, että asiakas itse oivaltaa ongelmansa olevan haaste, sen sijaan että se suoraan hänelle kerrottaisiin…)

Uuden vuoden toiveena pyydän kahta asiaa. Pyydän, että “haasteet” jätetään vuoteen 2011 ja tästä vuodesta tehdään ongelmien, hankaluuksien, kommervenkkien ja takaiskujen vuosi!

Onko tämä kompa vai yritänkö vetää lukijaa nenästä? Kyllä ja ei. Siksi vähän pidempi vastaus: Älä rakenna itse sellaista skaalautuvuutta, jonka joku muu on jo ratkaissut (ja jota voit hyödyntää).

IaaS- ja PaaS -markkinoilla on paljon skaalautuvia infra- ja middlewareratkaisuja joissa toimittaja ottaa vastuun [...]]]> Miten rakennat järjestelmän, joka skaalautuu 100 miljoonalle käyttäjälle? Vastaus: Et rakenna.

Onko tämä kompa vai yritänkö vetää lukijaa nenästä? Kyllä ja ei. Siksi vähän pidempi vastaus: Älä rakenna itse sellaista skaalautuvuutta, jonka joku muu on jo ratkaissut (ja jota voit hyödyntää).

IaaS- ja PaaS -markkinoilla on paljon skaalautuvia infra- ja middlewareratkaisuja joissa toimittaja ottaa vastuun palvelun skaalautumisesta, ja tilaajan vastuulle jää laskun maksaminen. Yksinkertaisen esimerkin saa tehtyä Amazon Web Service:n S3-tiedostopalvelulla sekä SQS-viestijonopalvelulla. Alla on esimerkkikuva arkkitehtuurista jossa selain lukee tiedot S3:sta ja viestii taustajärjestelmälle vain SQS:n kautta:

Järjestelmä toimii siten, että kohdassa A taustajärjestelmä työntää S3:een tiedot, jotka asiakasohjelma (selain) hakee kohdassa B. Selaimessa pyörivä ohjelma interaktoi käyttäjän kanssa ja lähettää tarvittaessa asynkroniset palvelupyynnöt taustajärjestelmälle SQS:n kautta kohdassa C. Taustajärjestelmä purkaa sitten SQS-jonoa omaa tahtiaan kohdassa D.

Jotta tämä keskustelu ei jäisi teoreettiselle tasolle, esittelen nyt (rummunpäristystä) palvelun nimeltä spingy. Kyseessä on yksinkertainen järjestelmä, joka pingailee käyttäjien määrittelemiä internet-palvelimia ja piirtää sitten käyttäjälle nätin kuvaajan palvelimen verkkotason latenssista. Tähän malliin:

Spingy toimii siten, että taustapalvelin pingailee palvelimia omaan tahtiinsa ja ajoittain työntää tulostietoja S3:een. Asiakasohjelma on selaimessa toimiva javascript-pohjainen ohjelma, joka hakee raakadatan S3:lta ja piirtää näistä kauniit kuvat. Presentaatiokerros ja sen aiheuttama kuorma on siis sataprosenttisesti selaimessa. Tiedonsiirron skaalautumisen hoitaa S3. Taustajärjestelmä itsessään ei näe käyttäjien aiheuttamaan kuormaa kuin pingattavien koneiden lukumäärän kasvuna – joka oletettavasti kasvaa hitaammin kuin käyttäjien määrä, koska julkisessa internetissä on kiinni vähemmän tietokoneita kuin planeetalla on ihmisiä.

Taustapalvelimena on yksi mikroinstanssi. Siis 1 – uno, ett, one. Enempää se ei edes tarvitse. Alunperin asetin spingylle tavoitteeksi 50 000 koneen pingauksesta kaksi kertaa tunnissa ja ainakin penkkitesteissä tämä saavutetaan helposti:

• Yli 400 000 pingiä tunnissa yksisäikeisenä (CPU ei noussut yli 10%, joten tuota voisi rinnakkaistaa moninkertaisesti)
• Yli 120 000 käsiteltyä ja vastaanotettua SQS-viestiä tunnissa (myös yksisäikeisenä)

SQS:ään pystyn työntämään uusia viestejä yhdeltä koneelta myös riittävän nopeasti (>200 000/h), mutta koska spingyn selainpää normaalisti lähettää vain muutamia viestejä päivässä, ei asiakaspään viestien lähetyksen kaistanleveydellä ole niin suurta merkitystä. En ole erikseen testannut SQS:n suorituskyvyn rinnakkaistumista, joten se on tässä kohtaa pelkkä oletus. (200 tuhatta viestiä tunnissa ei viestijärjestelmille ole itsessään kummoinen tulos, mutta tähän käyttöön enemmän kuin riittävä.)

Vaikka S3 on “tunnetusti” skaalautuva, päätin silti testata sitä. Ajoin Cloud Assaultilla testin 250 rinnakkaisella clientillä. Testi tosin latasi vain Spingyn etusivua, mutta sekin on S3:ssa. Tuloksena oli tasaisesti yli 1300 latausta sekunnissa.

Miten hyvin tämä toimii oikeasti? Ehkä se ei ole niin relevanttia. Kyseessä on kuitenkin tekninen demo, ei kaupallinen ratkaisu. Demona se esittelee yhden mallin tehdä skaalautuvia verkkopalveluita. Toiminnallisuudeltaan se on hyvin rajoitettu eikä sellaisenaan ole sovellettavissa muissa palveluissa – mutta ehkä mallina siitä, mikä on yksi tapa saavuttaa skaalautuvuutta.

Hmmm, luulen että kirjoitan Spingystä ja skaalautuvuusmalleista vielä jossain vaiheessa lisää.

P.S. Spingyn lähdekoodi on GPLv2:n alla ja löytyy githubista. Jos sinulla on parannettavaa koodiin tai vaikka ohjeisiin niin forkkaa ja laita pull request tulemaan!