Pilven hinta

Pilvi tunnetusti sopii hyvin palveluille,

  • jotka ovat maailmanlaajuisia (tai Euroopan/USAn markkinoille tähtääviä),
  • joiden käyttöaste vaihtelee, tai
  • jotka tarvitsevat skaalautuvuutta.

Mutta entä pienehkö, yhdellä koneella hyvin pyörivä Suomen markkinoille suunnattu palvelu? Onko sellaiseen mitään järkeä käyttää pilvi-infraa?

Latenssi on tietysti yksi kysymys, kun toistaiseksi pilvikoneita ei saa Suomesta eikä edes Ruotsista.Pingi Amazonin Irlannin konesaleihin on noin 80 millisekunttia. Jos vajaan sadan millisekunnin latenssi ei ole ongelma, seuraava kysymys on hinta. Tieken Vinkkejä&Viiniä-illassa useampikin ihminen esitti, että Amazonin käyttäminen tulee kalliimmaksi, kuin kotimaiset virtuaalipalvelintarjoajat. Väitän, että näin ei ole.

Otetaan lähtökohdaksi pienehkö webipalvelu. 10 000 sivulatausta päivässä, keskimäärin 100kB kappaleelta. Pyyntöjä tulee tiheimmillään muutama sekunnissa, eli normaali 1-coremylly riittää hyvin. Muistia tarvitaan gigatavu, ja kovalevyä 40 gigaa.

Oletetaan, että toimiston nurkassa makaava vanha romu ei nyt ole vaihtoehto, vaan palvelu pitää saada ammattimaisesti hostatuksi joko suomalaisille virtuaalipalvelintarjoajille tai Amazonin pilveen.

Suomalaisina tarjoajina toimivat tässä Nebula, Sigmatic ja Louhi. Tarjoajat on valittu sillä perusteella, että heillä oli hinnastot netissä. Muistin määrä oli yllättäen tässä kynnys: Nebulalla ja Louhella giga oli suurin tarjolla oleva koko, Sigmaticilta olisi saanut kaksikin.

Nebulalla palvelimen sai kustomoida itse. Valinnat olivat Linux, 1GB muistia, 40GB levyä ilman varmuuskopiointia. Hinta 109€/kk. Sigmaticilla ominaisuudet on kasattuna paketeiksi, ja vaatimuksia vastaava Standard V3 maksaa 90€/kk. Louhen Pro-paketti taas on 99€/kk. Yleisesti voi siis sanoa, että sopivan palvelimen saa noin satasella kuussa. Ja vähän ihmetyttää että kuka ja mihin käyttöön oikeastaan ostaa niitä virtuaalikoneita 256 megan muistilla.

Amazonin Elastic Cloud 2-virtuaalikoneiden tarjonnassa pienin muistin määrä on 1,7 gigatavua. Sen tarjoavalle small instanssille tulee Irlannista ostettuna hintaa $0,095 tunnilta, eli noin 47 euroa 50 senttiä kuussa.

EC2-instanssien kovalevyt eivät ole persistenttejä, eli niille ei pidä tallentaa tietokantaa. Ostetaan siis erikseen Elastic Block Device-levyä. EBS:n laskutusperuste on toteutunut käyttö. Kun aiemmin tarvitsimme 40GB, tästä osa meni käyttöjärjestelmälle, ohjelmakoodille, jne ja osa taas on varalla reservissä. Oletetaan tietokannan ja muun dynaamisen datan vievän 30GB. Luultavasti yläkanttiin, mutta sillä ei ole juuri väliä, koska hinta on $0,11 alkavalta gigatavulta kuussa, ja lisäksi $0,11 miljoonaa I/O-requestia kohden. Sivulatauksia tulee kuussa 300 000 joten I/O-requesteja voisi olla 3 miljoonaa. Kokonaishinnaksi tulee siten 2 euroa 50 senttiä kuussa.

Lisäksi pitää maksaa liikenteestä. Palvelusta ladataan sivuja yhteensä 30 gigatavua kuussa. Sisään päin liikennettä tulee tuosta sadasosa. Ulospäin liikenne maksaa $0,17 gigatavulta ja sisäänpäin se on tällä hetkellä ilmaista. Yhteensä siis 3 euroa 50 senttiä kuussa. Kesän jälkeen sisäänpäin tuleva liikenne alkaa taas maksaa $0,10 gigalta, eli kuukausikustannus nousee seitsemällä eurosentillä.

Amazonin hinnaksi tulee siis: virtuaalikone 47,50€ persistentti kovalevy 2,50€ liikenne 3,50€, yhteensä 53 euroa 50 senttiä kuussa.

Amazonin hinta on siis noin puolet kotimaisten tarjoajien hinnasta. Kotimainen pieni palvelukin voi siis hyvinkin kannattaa siirtää pilveen, jovähän suurempi latenssi ei ole ongelma. Lienee myös vain ajan kysymys ennen kuin joku alkaa tarjota pilvi-infrastruktuuria Pohjoismaissa, esimerkiksi Google Haminasta käsin.

Tässäkin laskelmassa tuli hyvin esiin, kuinka pilven hinnoittelu ei ole yksinkertaista. Hintojen ymmärtäminen aiheuttaa tietenkin ylimääräistä vaivaa, mutta toisaalta se mahdollistaa optimoinnin: asiakas maksaa vain liikenteestä, kovalevystä ym jotka tarvitsee. Tämän esimerkin kokoluokassa senteillä ei kauheasti kannata nyplätä, mutta kun puhutaan sata kertaa suuremmista palveluista, hyvällä arkkitehtuurilla saatavat säästöt ovat jo merkittäviä.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Miksi palvelu ei salli käyttäjätunnuksen muuttamista?

Olet varmaan joskus rekisteröitynyt nettipalvelun käyttäjäksi, ja jälkikäteen harmitellut että joitain jättämiäsi tietoja ei pääse jälkikäteen enää muuttamaan.  Usein kyseessä on käyttäjätunnus, oman valinnan mukaan tai ehkä sähköpostin tai puhelinnumeron muodossa. Minkä takia käyttäjätunnusta usein ei sallita muuttaa?  Muuttamisen tarve voi useinkin olla asiallinen, ja rajoitus nähtävästi mielivaltainen.

Tilanne johtuu useimmiten siitä, että järjestelmän suunnittelija on tietokantaa suunnitellessa valinnut luonnollisen avaimen (engl. natural key) perusavaimeksi (engl. primary key), niin kuin esimerkiksi käyttäjän sähköpostiosoitteen, puhelinnumeron tai itse valitseman tunnuksen.  Perusavainta tarvitaan yksittäisten tietokantarivien yksilöimiseen, ja eri syistä perusavaimen päivittäminen tietokannassa usein on epäkäytännöllistä.  Tästä johtuen järjestelmän suunnittelija yleensä ei tue toimia, joka vaatii perusavaimen muuttamista. Jos perusavain on luonnollinen avain, tästä seuraa myös että kyseisen luonnollisen avaimen kentän (esim. sähköpostiosoitteen) muuttamista ei tueta — vaikka tälle olisi asiallinen tarve.

Tilanne ei ole kuitenkaan välttämätön.  Suunnittellessa tällaisia järjestelmiä kannattaa harkita toteuttamisvaihtoehtoja perusavaimelle: käyttää luonnollista avainta, josta voi seurata yllä mainittu tilanne, tai niin kutsutun keinoavaimen (engl. surrogate key) käyttöä. Luonnollinen avain tulee tosimaailmasta (esim. käyttäjän sähköpostiosoite, puhelinnumero tai oma tunnus), kun keinoavain taas on joku pelkästään tähän tarkoitukseen luotu avain (esim. juokseva kokonaisluku).

Eli vaikka tietomallista löytyy luonnollisia avaimia, niitä ei ole pakko käyttää perusavaimina. Sen sijaan voi tarkoituksella luoda keinoavaimen, joka ei ole riippuvainen käyttäjän tiedoista.  Keinoavaimen suurin hyöty on siis se, että se on täysin riippumaton tosimaailmasta, joten kaikki käyttäjän tiedot ovat muutettavissa, mukaan lukien luonnolliset avaimet.  Tällä tavalla käyttäjä pääsee vapaasti muuttamaan kaikkia tietojansa järjestelmässä, ilman rajoitteita.

Seuraavan kerran kun itse olet suunnittelemassa tietokantaa, harkitse kumpi on se parempi perusavain järjestelmällesi: keinoavain vai luonnollinen avain.  Myös sovelluksen käyttäjän näkökulmasta!

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Versionhallinnan vajaakäyttö

Ohjelmistoja tuottavat organisaatiot tyypillisesti käyttävät versionhallintaa. (Jotkut eivät, vaikka tietävät, että pitäisi. Mutta ei heistä tänään.)  Versionhallintahan on helppoa, kun sen osaa. Vai onko? Tarkastellaanpa asiaa lähemmin.

Kaikki versionhallintaa käyttävät softaorganisaatiot luovat uusia projekteja versionhallintaan, lisäävät uutta koodia, ajoittain jopa palaavat vanhempiin versioihin huomattuaan tehneensä virheitä. Jostain syystä laajamittainen versionhallinnan käyttö tuntuu rajoittuvan tähän.

Branchien käyttö on  vierasta monille. En nyt väitä, että brancheja käyttää vain koodarien kärkiprosentti, tai jotain vastaavan älytöntä. Väitän, että yli puolelle branchit kuitenkin ovat käsitteenä tuttuja, ja ehkä kysyttäessä vastaukseksi saa “totta kai osaan käyttää versionhallintatyökalussani brancheja”. Kuitenkin käytännön toimintaa tarkastellessa brancheja ei koskaan käytetä.

Mistä tämä johtuu? Aiheuttaako tämä haittoja? Voitaisiinko asialle tehdä jotain?

Pidän syitä lähinnä historiallisina. Vanhoissa versionhallintatyökaluissa (CVS ja kaikki sitä edeltävä) branchien tekeminen oli kyllä helppoa, mutta mergeäminen usein työlästä.

Jos brancheja ei käytetä, mutta kuitenkin tehdään normaalia ohjelmistokehitystä, osa koodin hallinnasta tapahtuu väistämättä versionhallintatyökalun ulkopuolella. Tilapäiset kokeilut, päähaaraan kelpaamattoman koodin jakaminen työkaverin kanssa, uuden koodin siirtäminen erilliselle testaajalle tulevat kaikki hankalammaksi. Itse asiassa brancheja käyttämättömät organisaatiot usein sallivat päähaaraan koodia, jonka ainoa testaus on kehittäjän oma smoke test, usein vielä puutteellisemmin ainoa testaus on kääntyykö koodi.

Tilanteen korjaus alkaa sillä, että varmistetaan käytössä olevan modernin versionhallintajärjestelmän, jossa mergeäminen on mahdollisimman yksinkertaista. Jopa Subversion täyttää tämän ehdon. Distributoitujen versionhallintajärjestelmien muut edut saattavat tosin puoltaa siirtymistä niihin, jos järjestelmänvaihtoon ryhdytään.

Organisaatiossa tulee eksplisiittisesti käsitellä versionhallinnan käyttöä. Versionhallinnan käytännöistä ei ole ainakaan tällä hetkellä yhtä oikeaa tapaa, jonka voitaisiin olettaa olevan kaikille alan ammattilaisille tuttu. Koska on monta oikeaa tapaa, pitää valita niistä yksi, ja tehdä selväksi mikä on valittu.

Tässä muutamia käyttötapauksia, joiden avulla voi miettiä, ovatko versionhallintaprosessit kunnossa. Jokaisessa kysymys on, onnistuuko tehtävä versionhallinnan sisällä, vai pitääkö siitä poistua ja joutua ad hocin vaaralliseen maailmaan.

  • Poistun töistä ja jatkan kotona täysin keskeneräisen toiminnallisuuden toteuttamista.
  • Saan toiminnallisuuden valmiiksi ja annan sen testausosastolle testattavaksi. En voi laittaa sitä päähaaraan, koska en tiedä rikkooko se softan kaikille muille.
  • Toimitan asiakkaalle testatun snapshotin koodista
  • … jota sekä asiakas että Codento ovat kehittäneet sitten viimeisen synkronisaation
  • … ja asiakkaan versionhallintaan ei meillä ole suoraa pääsyä.
  • Totean kesken olevan ominaisuuteni olevankin oikeasti kaksi ominaisuutta, ja jaan kehityshaaran kahtia ja luovutan toisen Santerille.

Tämän kaiken mahdollistaminen on nykyisillä versionhallintatyökaluilla enemmänkin hallinnollinen ja organisaatiokulttuurillinen ongelma kuin tekninen. Subversion toimii. Mercurial toimii (kunhan siinä on local branchs -laajennus). Git toimii (kunhan dokumentaation yliteoreettisuudesta päästään yli, esimerkiksi kirjoittamalla runsaasti esimerkkejä siitä, kuinka paikallisten käytäntöjen mukaan toimitaan).

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.