2009-11-24

Google App Engine-kokeilun tulokset täällä

Päivitys 20.5.2010: Google on nyt päivittänyt GAE:n huomattavasti paremmat profilointiominaisuudet kuin mihin tässä kommentissa viitataan, eikä 1000 hakutuloksen raja ole enää voimassa.

Asiaan vihkiytymättömille: Google App Engine on Googlen oma tuote, jonka tehtävä on ajaa päivittäiskäytössä kehittäjien rakentamaa ohjelmistoa, joka tuottaa verkkosivuston, ja tallettaa käyttäjien tiedot.

Se on suunnattu cloud-markkinoille, joka on hieno tapa sanoa että tietojenkäsittelykapasiteettia ostetaan kevyellä, joustavalla prosessilla, tilastollisen tarpeen mukaan, vähän kuin sähköä tai maitoa.

Jutun juju on siinä, että cloud-myyjä osaa ennustaa tilastollisesti, kuinka paljon kapasiteettia tarvitaan ensi kuussa, ja cloudia käyttävät yksittäiset projektit voivat hankkia kapasiteettia vakiotuotteina, vähän kuin litran maitoa kaupasta, sen sijaan että pitäisi tietää kyseisen lehmän nimi ja lempiruoka kolme kuukautta etukäteen. Kun projektit saavat nopeata joustoa yllättäviin tarpeisiin, ne onnistuvat edullisemmin, ja lähempänä aikatauluaan.

Google App Engine kilpailee cloud-markkinoilla Amazon Web Services-palveluperheen kanssa, ja Mansikki-markkinoilla PHP/MySQL-konseptin ja sitä käyttävien superhalpojen laaduttomien alustatuotteiden kanssa.

No niin, itse asiaan!

Olen testannut GAE:ta pari kuukautta aika simppelillä sovelluksella, jota olen käyttänyt päivittäin.

Aloitin kehityksen vielä silloin, kun GAE ei tukenut Javaa, joten sovellus on Pythonia.

Kehitysprosessi on varsin kömpelö. GAE-työkalut sisältävät paikallisen kehityspalvelimen, mutta siinä ei ole valmista tapaa synkronoida tietokantaa Googlen palvelimilta paikalliseen ympäristöön, joten tuotantodatasetin saaminen kehitykseen on varsin hankalaa.

Suurin ongelma minulle on kuitenkin se, että kaikki sovelluksen tieto tallennetaan Googlen omaan tietokantajärjestelmään, jonka luku/kirjoituslatenssia on erittäin vaikea ennustaa. Heidän tietokantansa ei tue SQL JOIN-rakennetta, ja se ei voi palauttaa vastauksena yhteen kyselyyn kuin 1000 tietuetta.

Toinen ongelmallinen kohta on koodin suorituskyky ja profilointi. Pääsivun luominen kestää melkein 2 sekuntia, vaikka cachetan suurimman osan datasta. Googlen profilointimetodit eivät palauttaneet mitään olennaisen hyödyllistä tietoa jonka perusteella voisin tehdä johtopäätöksiä. Lisäksi osa Googlen palvelurajapinnoista ei toimi dokumentaation mukaisesti, ja tietysti myös ihan olennaisesti eri tavalla paikallisessa kehityspalvelimessa, ja Googlen tuotantopalvelimessa.

Siirrän sovelluksen GAE:sta paikallisesti pyöriväksi Java-sovellukseksi. En suosittele GAE:ta vielä otettavaksi käyttöön, ilman varsin kattavaa tietokantahakujen testausta todellisilla tuotantotietomäärillä.

Powered by Google App Engine

Addendum: Paras tapa saada data ulos GAE:sta on http://code.google.com/appengine/articles/remote_api.html. Heillä on roadmapissa parempi importti/exportti, mutta näkee sitten.

2009-11-21

Haluan parantaa ohjelmistoinvestointien tuottavuutta

Yritysohjelmistojen joustamattomuus liiketoiminnan muutoksiin on laatuongelma, jota uskaliaskaan prosessikehitys ei tähän mennessä ole saanut kuriin.

Sen kanssa eletään sinnittelemällä joustamattomien järjestelmien kanssa, kunnes on taas aika uudelle isolle kehitysprojektille.

En enää jaksa uskoa, että tälle ongelmalle olisi yhtä isoa ratkaisua.

Sen ytimessä ovat ihmiset, tilaaja-toimittajasuhteen rakenne, ja syvälle juurtunut tapa budjetoida IT-varoja liiketoiminnan kehittämispyrähdyksinä, eikä sen jatkuvana pyörittämisenä.

Tämä kaikki johtaa lopulta siihen, että liiketoiminnan kehittyviin tarpeisiin taipumattoman koodin suunnittelijan ja kirjoittajan ensi tason työnvalvonta viestii tekijöille prioriteetteja, jotka peilaavat ensi sijassa toimittajaorganisaation rakenteellisia tavoitteita.

Toimittajien kehittäjät eivät yleensä ottaen ole hölmöjä tai epäpäteviä, vaikka tilaajan projektihenkilöstö joskus muodostaakin sellaisen mielikuvan.

He mittaisivat tekemiensä ratkaisujen oikeutta tai vääryyttä projektin ja asiakkaan pitkän tähtäimen tavoitteiden mukaan, jos heille viestittäisiin niistä uskottavasti osana päivittäistä rutiinia.

He oppisivat yhdistämään tavoitteet omaan työhönsä, jos laatua kontrolloitaisiin, ja poikkeamista viestittäisiin, osana päivittäistä rutiinia.

Tällä hetkellä tälläistä roolia ei ole. Laatua kontrolloidaan liian pitkällä syklillä jotta siitä oppiminen olisi rutiinia, ja sairauksien sijaan hoidetaan oireita.

Yksinään tälläisen viestivän lähettiläsroolin lisääminen ei ratkaise koko laatuongelmaa, mutta jos me emme etsi parempaa huomista, niin kuka sitten?

Tiedostetaanko teillä tämä ongelma IT-kehitysprojektien suhteellisesta tuottamattomuudesta, liiketoiminnan muuttuviin tarpeisiin joustamattomuudesta, ja turhista jännitteistä?

Tehdään asialle jotain yhdessä!