Websovellusten hostingin yleisin virhe kumpuaa vääristä oletuksista

Websovellusten hostingin yleisin virhe kumpuaa vääristä oletuksista

Kokenut järjestelmäasiantuntija Lupu Pitkänen avaa kolmiosaisessa blogisarjassa, mitä hän on oppinut vuosien varrella pystyttäessään satoja hosting-ympäristöjä. Ensimmäisessä osassa hän paljastaa, miten vältät yleisimmän websovellusten ja -sivustojen hostingissa tehtävän virheen.

Urani internet-palvelujen parissa alkoi jo 1990-luvun lopussa, kun toteutimme asiakkaille websivustoja, verkkokauppoja ja extranet-järjestelmiä. Vuosituhannen vaihteessa siirryimme projektitoiminnasta sovellusvuokraukseen (nykyisin puhutaan Software as a Service eli SaaS-pilvipalveluista) tarjoamalla työkaluja mm. kiinteistönvälittäjille, messuille ja logistiikkayrityksille.

Näinä vuosina sain jo arvokasta kokemusta websovellusten hostingista. Silloiset palveluntarjoajat elivät kuitenkin omissa norsunluutorneissaan, eivätkä nähneet minkälaisia tarpeita kehittäjillä ja asiakkailla oli hostingin suhteen. Hyvää palvelua oli vaikea saada, ja hostingia myytiin vain gigatavuina tai megabitteinä. Päätimme parantaa tilannetta omalta osaltamme. Vuonna 2002 perustettiin Planeetta Internet.

Käsieni kautta on kulkenut satoja fyysisiä ja tuhansia virtuaalipalvelimia. Olen palvellut lukemattomia asiakkaita websovellusten ja sivustojen hostauksessa. Tässä blogisarjassa jaan vuosien varrella oppimiani asioita ja havaintoja. Uskon, että niistä on hyötyä kaikille, jotka pohtivat työssään web-sovellusten hostaukseen liittyviä kysymyksiä.

Ensimmäisessä osassa luovitaan nyt kaikkein yleisimmän karikon ohi, mihin olen huomannut hostingissa törmättävän. Toisessa osassa pureudutaan perustamisvaiheeseen ja käyttöönottoon (deployment), kolmannessa taas tuotantovaiheeseen ja ylläpitoon (operations).

Väärillä olettamuksilla metsään

Miten websovelluksen hosting-palvelu yleensä valitaan?

Oletusarvoilla. Joko tyydytään ensimmäiseen vastaantulevaan palveluun tai käytetään vuodesta toiseen samaa toimintamallia kuin aina ennenkin. Eri vaihtoehdoista on usein liian vähän tietoa. Aluksi sopivalta tuntunut alusta voi aiheuttaakin ongelmia kun sovellus tai sivusto on jo tuotannossa. Tarkoitan tässä ensisijaisesti palvelun tyyppiä, vaikka sama pätee myös palveluntarjoajan valintaan.

Perinteinen webhotelli (shared hosting) voi riittää pienelle staattiselle sivustolle tai blogille. Skaalautuvuudesta, tietoturvasta ja toimintavarmuudesta tingitään kuitenkin rajusti, koska samalla palveluntarjoajan palvelimella ajetaan mahdollisesti useiden satojen eri asiakkaiden sivustoja.

Infrastruktuuri pilvipalveluna (IaaS = Infrastructure as a Service), eli tyypillisesti virtuaalipalvelin, on houkutteleva vaihtoehto runsaan tarjonnan ja edullisten hintojen vuoksi. Omiin fyysisiin palvelimiin verrattuna se onkin hyvä vaihtoehto. Monesti unohtuu kuitenkin sovellusalustan konfiguroinnin, ylläpidon, valvonnan, varmistusten ja tietoturvan huolehtiminen.

Harvaa sovellusta voi nimittäin ajaa sellaisenaan pelkän IaaS-kapasiteetin päältä, vaan yleensä tarvitaan myös sovelluskerros (esim. PHP, Java, Node.js) riippuvuuksineen. Mahdollisesti raaka palvelinkapasiteetti taipuu toimestasi päteväksi sovellusalustaksi esimerkiksi konfiguraatioautomaation avulla. Silloin kannattaa kuitenkin pohtia keskitytkö asioihin, jotka tuottavat asiakkaallesi lisäarvoa. Oletko myös valmis ottamaan vastuun sovellusten toimivuudesta tuotannossa 24/7 periaatteella?

Valmis sovellusalusta (PaaS = Platform as a Service) on vähemmän tunnettu ratkaisu edellä mainittuihin haasteisiin. Tällöin palveluntarjoaja vastaa kaikista sovelluskerrokseen liittyvistä asioista ja voit keskittyä sovelluskehitykseen ja lisäarvon tuottamiseen.

Perinteiset PaaS-alustat saattavat edellyttää sovelluksen koodaamista juuri kyseistä pilvipalvelua varten. Viime aikoina kovassa nosteessa olleen Docker-konttiteknologian käyttö mahdollistaa sovelluksen ja sen vaatiman ympäristön täydellisen liiton, mutta se siirtää silti paljon vastuuta hostingista kehittäjälle. Yksi vaihtoehto on ylläpidetty IaaS-kapasiteetti, jossa joko palveluntarjoaja tai erillinen konsultti vastaa sovelluskerroksesta ja tuottaa käyttövalmiin PaaS-alustan palvelinkapasiteetin päälle.

Vastuut isossa roolissa

Vääränlaisen palvelun aiheuttamiin haasteisiin herätään yleensä vasta, kun ongelmat alkavat. Mahdollisesti seuraa syyllisten etsintä ja syyttömien rankaisu.

Elämällä olettamusten varassa voidaan kuvitella esimerkiksi IaaS-kapasiteetin tarjoajan hoitavan tietoturvapäivitykset (on toki mahdollista, mutta onko siitä sovittu?) tai pienen kehittäjätiimin vastaavan 24/7/365 periaatteella sovellusalustan toiminnasta.

Vastuukysymykset ovatkin keskeisin asia oikeanlaisen palvelun valinnassa. Hoitaako sovelluskehittäjä oman toimen ohellaan palvelinten konfiguroinnin? Kuka vastaa ylläpidosta ja tietoturvasta? Miten reagoidaan jos tärkeä websovellus tai verkkokauppa lakkaa toimimasta kehittäjän työajan ulkopuolella?

Tärkeintä on siis hahmottaa jo aikaisessa vaiheessa, kuka vastaa mistäkin ja miten vastuut jakautuvat eri toimijoiden kesken.

Vastuukysymyksiä sivutaan myös blogisarjan seuraavissa osissa. Aihepiiriä käsitellään myös ilmaisessa ”Oletko pilvinatiivi vai palvelimen vanki? Webhostingin evoluutio” -webinaarissamme. Webinaari pidettiin huhtikuussa 2016.
TUTUSTU HOSTING-PALVELUIHIMME