Sovellusten virtualisointi (OSA 3)

Yleisin kysymys kun lähdetään miettimään sovellusten virtualisointia on, että voiko sovelluksen X virtualisoida. Vaikka olen satoja sovelluksia virtualisoinut, ainoa oikea vastaus on ehkä. Käytössä on niin monia eri sovelluksia ja niiden eri variaatiota, että on mahdotonta antaa täysin varmaa vastausta ilman testaamista asiakas ympäristössä.

Seuraavaksi yleisin kysymys on Microsoft Office 2007 (2003), tähän vastaus on että voi, mutta ei kannata. Miksi ei kannata on se. että niin monet muut sovellukset linkittyvät officen palveluihin (sähköposti, excel...) tai asentavat lisäosia officeen. Näiden takia en itse suosittele vielä Officen virtualisointia, yleensä sen kanssa on ajauduttu ennemmin tai myöhemmin ongelmiin ja jouduttu palamaan takaisin perinteiseen asennukseen.

Mistä sitten sovellusvirtualisointi aloitetaan?

Liiketoimintasovellukset on yleensä se mistä lähdetään, koska yksi sovellusvirtualisoinnin (samoin kuin työasema/palvelin virtualisoinnin) tärkein ominaisuus on varmistaa sovelluksen toiminta. Miten se sitten varmistaa sovelluksen toimintaa? Yleensä liiketoimintasovellukset ovat ns. client/server sovelluksia, jotka tarvitsevat itse sovelluksen lisäksi myös muita komponenteja (oracle client, Java versio x.x, .Net Framework x.x jne.) sekä asetuksia (rekisteri, ini tms.) toimiakseen. Koska työasemissa usein on myös muita sovelluksia, jotka vaativat ehkä eri version tuosta komponentista tai eri määritykset rekisteriin tms. niistä aiheutuu tilanteita jossa sovellus A toimii, mutta B ei enää toimikkaan.

Sovellusvirtualisoinnilla voidaan varmistaa, että sovelluksen käytössä on aina oikeat komponentit, niiden versiot sekä oikeat asetukset. Tämä saadaan aikaan kun nämä tarvittavat lisäosat paketoidaan sovelluksen mukaan tai nyt uudemmilla virtualisointiohjelmilla linkitetään nämä lisäosat.

Miten sovellusvirtualisointiprojekti etenee?

Yleensä projekti aloitetaan kartoittamalla käytössä olevat sovellukset. Tästä listasta valitaan ensimmäisessä vaiheessa virtualisoitavat sovellukset. Kannattaa muistaa ettei kannata pyrkiä virtualisoimaan heti kaikkia sovelluksia, vaan tehdään siirtymäsuunnitelma jonka mukaan edetään. Aika usein löytyy sovelluksia, jotka pitäisi päivittää lähiaikoina tai käyttöön on tulossa uusia sovelluksia. Nämä ovat niitä, joille jo ilman virtualisointiakin pitäisi tehdä jotain, joten nämä ovat niitä joista aloitetaan.

Muitten sovellusten osalta laaditaan aikataulutus (esim. seuraava versio/päivitys tms.) jonka mukaan jatkossa edetään. Kuten kaikki tietävät on sovellusten päivitys / uusien asennus / poisto jatkuvaa työtä, eli valmista ei tule koskaan. Koska kuitenkin projektilla pitäisi olla myös loppu, mietitään mitkä sovellukset kuuluvat varsinaiseen projektiin ja mitkä jatkokehitykseen (tuotantoon).

Käytännön esimerkki

Olin virtualisoinut (Thinstall) asiakkaalle sovelluksen joka käytti Oracle 8 clienttiä, sovellus oli toiminut pitkään ok. Nyt sovellukseen oli tulossa päivitys, joka muutti Oracle 8 Oracle 10:een. Käytössä oli myös toinen sovellus, joka edelleen käytti Oracle 8 clienttia. Jos sovellukset olisivat asennettu perinteisesti, nyt olisi ollut edessä aika haastava tehtävä saada molemmat toimimaan yhtäaikaa työasemassa. Mutta koska molemmat sovellukset oli virtualisoitu, voitiin toinen sovellus päivittää käyttämään Oracle 10:ä paketoimalla se virtuaalipaketiin yhdessä sovelluksen kanssa. Meidän ei tarvinut testata sovellusten yhteentoimimista koska molemmilla oli paketin sisällä oma Orale client. Sovelluksesta tehtiin uusi paketti (MSI) ja pantiin jakeluun.

Seuraavaksi teemme eri client (Oracle, Java, .NET) ohjelmistoista omat paketit, jotka jatkossa linkataan sovelluspaketteihin. Tällöin itse sovelluksen päivitys helpottuu, koska jakelussa ei enää tarvitse mennä isoa clienttia mukana. Eli kun saamme ThinApp 4.0:n.

ThinApp päivitys on myöskin helppo tehdä, koska siinä client on paketissa (exe tai msi) mukana ja eri versioilla tehdyt virtuaalipaketit toimivat hyvin rinnakkain.