Siirtymisen yleiset periaatteet
MUULI
Joitain termejä
Tässä lyhyessä siirtymisen periaatteiden dokumentissa käytetään seuraavia termejä seuraavanlaisessa merkityksessä.
- Palvelualusta = tietokonelaitteiston (esimerkiksi työasema tai palvelin), sen käyttöjärjestelmän (esim. Linux tai MS Windows), käyttöliittymän ja tarvittavien peruspalveluiden kuten mahdollisen tietokannan ja web-palvelimen muodostamaa kokonaisuutta, johon palvelun tuottama ohjelmisto asennetaan. Rajanveto on keinotekoinen, eikä määritelmää voi käyttää kovin yleisesti. Esimerkiksi englanninkielinen wikipedia antaa hieman eri määritelmän, ks. Service delivery platform
Yleistä järjestelmien palvelualustan vaihdosta
Siirryttäessä suljetusta palvelualustasta / järjestelmästä avoimeen ratkaisuun pitää toteuttaa normaali ohjelmistoprojekti. Siirtymä kannattaa suunnitella etukäteen hyvin ja se kannattaa testata mielellään jossain erillisessä testiympäristössä ennen kuin suunnitelma toteutetaan tuotantoympäristöön.
Palvelualustan vaihtosuunnitelma kannattaa arvioida kustannus-tuotto -vertailun avulla. Vaikka avoimet ratkaisut tuovat itseisarvona muutamia hyviä ominaisuuksia, kuten tuen helpon kilpailutettavuuden ja tietyntasoisen ylihinnoittelun vaikeuden, niin silti ei ole mitenkään itsestään selvää että kaikissa tilanteissa avoin palvelualusta olisi kustannustehokkain vaihtoehto. Kustannuksia laskettaessa kannattaa nimittäin ottaa huomioon esimerkiksi oman henkilökunnan osaaminen / koulutustarve. Jos osaamista avoimista ratkaisuista ei ole, niin niihin siirtymisen kustannukset nousevat.
Miksi vaihto monissa tapauksissa kannattaa
Tietokoneiden nopea kehittyminen on johtanut tilanteeseen, jossa uuden tietojärjestelmän käyttö vaatii aluksi käyttöönottoajankohdan mahdollistamia erittäin tehokkaita klusteroituja ratkaisuja. Muutaman vuoden aikana tapahtuva tietotekniikan kehittyminen tuo kuitenkin tätä klusteroitua ratkaisua vastaavan suorituskyvyn peruspalvelimeen. Kun samalla hankitun klusteroidun laiteratkaisun ikä saavuttaa kriittisen rajan (esim. 5 vuotta) niin sen tekninen ylläpito vaikeutuu (mm. komponenttien saatavuus heikkenee) ja tämä vaikeutuminen näkyy myös ylläpitomaksuissa. Useiden tietojärjestelmien elinikä on kuitenkin yli kymmenen vuotta, joten suoritusvaatimusten arviointi kannattaa tehdä muutaman vuoden välein. Samoin järjestelmän kriittisyys ja luotettavuusvaatimukset voivat pienentyä mm. silloin kun järjestelmä osittain korvataan uudella.
Toinen merkittävä säästömahdollisuus saavutetaan lisenssimaksuissa. Suurien järjestelmien ohjelmistojen tyypillinen ominaisuus on suuret lisenssikustannukset. Vaikka järjestelmä vanhenee ja sen suhteellinen suorituskyky heikkenee (verrattuna normaaleihin uusiin työasemiin) niin lisenssimaksut eivät tyypillisesti pienene ajan kuluessa. Esimerkiksi kalliin (mutta vanhan) tietokantaratkaisun voi onnistua korvaamaan uudella lisenssimaksuttomalla ratkaisulla.
Kolmas mahdollinen säästö voidaan saavuttaa oman toiminnan tehostumisessa. Mitä helpommin esimerkiksi ylläpitäjät voivat kouluttautua sen paremmin työt tulevat tehdyiksi. Avoimien ratkaisujen yksi erinomainen puoli on siinä, että harjoittelu-/testiympäristöjä on suhteellisen helppo toteuttaa. Kun lisäksi avoimilla ratkaisuilla voidaan tehdä suuri osa palvelujärjestelmistä, niin voidaan saavuttaa yhtenäisen arkkitehtuurin tuoma tehostuminen.
Neljäntenä asiana kannattaa ottaa huomioon avoimien ratkaisuiden luonne "lähipalveluina". Esimerkiksi kuntien IT-palveluista maksamat rahat jäävät tyypillisesti omalle lähialueelle pyörittämään alueen liiketoimintaa. Avoin lähdekoodi onkin tässä suhteessa eräänlaista hyväksyttyä ja tehokasta aluepolitiikkaa.
Avoimiin järjestelmiin saatava tuki
Avoimien järjestelmien tukea pidettään usein virheellisesti vaikeasti saatavilla olevana. Kuitenkin yhä useammat toimittajat ovat sitoutuneet tukemaan joitain avoimia ratkaisuja ja toimittajariippumattomia tukijoita on useita. Avoimiin ratkaisuihin onkin helposti saatavilla kuukausimaksullisia tukipaketteja useilta eri toimijoilta. Toimijoita voi etsiä esimerkiksi COSSin sivujen ohjelmisto- ja yrityshakemistopalvelun avulla.
Avointen rajapintojen käyttö palvelukutsuissa
Avoimella rajapinnalla tarkoitetaan ohjelmiston dokumentoitua liittymäpintaa, jonka välityksellä eri ohjelmat voivat tehdä pyyntöjä ja vaihtaa tietoja eli keskustella keskenään.
Kun ohjelmisto käyttää palveluratkaisuihin (esim. käyttöjärjestelmä / tietokanta) suuntaan vain julkisesti sovittuja monen eri toimittajan hyväksymiä rajapintaratkaisuja saavutetaan tilanne, jossa tämä palvelu voidaan toteuttaa parhaiten tilanteeseen sopivalla ratkaisulla.
Tietokantatoimittajan omalle liiketoiminnalle on kuitenkin hyödyllistä mitä tiiviimmin asiakkaat saadaan sidottua toimittajan ratkaisuun. Tätä sitoumista on helppo vahvistaa sillä että toteutetaan sovelluksia käyttämällä näiden palveluratkaisuiden omia erityispiirteitä. Sovelluksen siirtäminen tulee huomattavan työlääksi, sillä ko. erityispiirteitä ei ole toteutettu muihin ratkaisuihin.
Tätä toimintatapaa monet palveluratkaisujen toimittajat pyrkivät suosimaan ja omasta järjestelmästä tehdään sellainen, jossa on helposti ja nopeasti toteutettavissa uusia sovelluksia erikoispiirteitä käyttämällä. Hankintatilanteessa loppuasiakkaalle saadaan toimitettua uusi sovellus hieman pienemmällä työmäärällä. Tämä hetkellinen hyöty kuitenkin tulee sovelluksen ylläpitovaiheessa maksamaan, sillä ohjelmiston käyttö edellyttää ko. palveluratkaisua alleen ja poistaa vapauden valita parhaiten tilanteeseen sopivan ratkaisun.
Asiakkaan kannattaakin pyrkiä arvioimaan valitun ratkaisun kustannukset pidemmällä aikavälillä, eikä vain hankintahinnan perusteella.
Tietokantavaihtoehdoista
Osa tietokantatoimijoista tekee nykyisiin ratkaisuihinsa kevennettyjä versioita. Mm. Oracle RAC (Real Application Cluster) on joissain tilanteissa korvattavissa kevyemmällä ei-klusteroidulla versiolla.
Yleisesti hyvin toimiviksi ja varsin suorituskykyisiksi avoimen lähdekoodin tietokannoiksi on todettu PostgreSQL ja MySQL.
Useihin ympäristöihin toteutetut kirjastot ja ohjelmointiympäristöt
Ohjelmointimielessä siirtymistä helpottaa kun käytetään kirjastoja ja ympäristöjä, jotka on toteutettu useaan eri käyttöjärjestelmään tai jotka tukevat useita eri tietokantoja, jne.
Ikkunointikirjastopuolella tälläinen on esimerkiksi WXWindows, joka on toteutettu ainakin Microsoftin Windows:iin ja useisiin eri UNIXeihin.
Oma selkeä nykypäivän siirrettävyyttä helpottava ympäristö on Java. Java on osin tulkattavana ympäristönä hieman tehottomampi kuin ns. natiivisovellukset, mutta siitä huolimatta se on saanut erittäin hyvin asemaa jopa palvelinkäytössä.
Erityispiirteitä Microsoft-ohjelmista siirtymiseen
Microsoftin itse tuottama ohjelmistojen tuottamisympäristö / komponenttikirjasto .NET on varsin paljon käytetty ympäristö nykyään. (Katso esim. Wikipedian selvitys .NET:sta.)
Yhtenä suurena ongelmana eri Windows-sovelluksien siirtämisessä toisella käyttöjärjestelmäarkkitehtuurille pidetään Microsoftin osin heikkoa dokumentaatiota käyttöjärjestelmän palveluiden toteutuksesta. Tätä ongelmaa pienentää näiden .NET-sovellusten osalta MONO, sillä .NET voidaan osittain korvata MONOlla (ks. myös Mono-projektin sivu).
Kannattaa myös ottaa huomioon Microsoftin itse tuottamat välineet muita käyttöjärjestelmiä varten. Esim. Microsoft on esim. tuottanut .NET-arkkitehtuurista oman versionsa FreeBSD:lle, Windowsille ja Mac OS X:lle. Tämän toteutuksen nimi on Shared source CLI.
Emulaattorien käyttömahdollisuus
Varsin monia ympäristöjä on mahdollista simuloida / emuloida toisella tietokoneella ja erityisellä ohjelmistolla. Tämän emulaattoriksi nimitetyn ohjelmiston käyttö on tehotonta, mutta koska tietoteknikka kehittyy niin nopeasti on vaihtoehto harkinnan arvoinen.
Emulaattorin yleinen periaate
Emulaattoriohjelma tarjoaa vastaavan palvelurajapinnan kuin sen emuloima laitteisto / käyttöjärjestelmä normaalisti tarjoaa. Emulaattori muuttaa suorittamansa ohjelman koodin ja järjestelmän palvelupyynnöt vastaamaan laitteiston todellista arkkitehtuuria ohjelman suorituksen aikana. Joissain tilanteissa emulaattori voi jopa lisätä ohjelman toimivuutta ja tietoturvaa, mutta yleisesti ottaen niissä ei tapahdu edistystä. Suorituskykyyn ajoaikaisella munnoksella on luonnollisesti heikentävä vaikutus.
Emulaattorin käyttötapauksia
Emulaattoria voidaan käyttää tehokkaasti sellaisissa tilanteissa, joissa suuren kokonaissiirtymän esteenä/hidasteena on vain yksittäisiä harvoin tarvittavia sovelluksia, joita ei voida muulla tavalla suorittaa ja joiden suorituskyky ei ole kriittinen. Näitä sovelluksia voivat olla esimerkiksi tässä kokonaisselvityksessä luokkaan "Ei-siirrettävät" -kuuluvat sovellukset, jotka on tehty muutamia vuosia sitten. Kirjoittajan omakohtaiset kokemukset Wine-sovelluksesta ja Delphillä toteutetusta ohjelmakoodista ovat erittäin lupaavia. Perusohjelmat toimivat loistavasti ilman minkäänlaisia ongelmia.
Palvelualustan virtualisointi
Tätä ei haluta käsitellä dokumentin tässä versiossa, mutta otsikko sopisi erinomaisesti tähän asiayhteyteen.
