Monoliittisen legacy-ohjelmiston pilvimigraatio Kubernetes-alustalle
Karhunen, Juho (2024)
2024
Tietotekniikan DI-ohjelma - Master's Programme in Information Technology
Informaatioteknologian ja viestinnän tiedekunta - Faculty of Information Technology and Communication Sciences
This publication is copyrighted. You may download, display and print it for Your own personal use. Commercial use is prohibited.
Hyväksymispäivämäärä
2024-05-14
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:tuni-202404093403
https://urn.fi/URN:NBN:fi:tuni-202404093403
Tiivistelmä
Legacy-ohjelmistot ovat yleisiä ja monille yrityksille tärkeitä tuotteita. Ne on suunniteltu ja kehitetty vanhoilla tekniikoilla ja teknologioilla. Ongelma legacy-ohjelmistoissa on se, että niiden ylläpito on aikaa vievää ja haastavaa.
Kirjallisuudessa on esitelty migraatiomenetelmiä, joilla sovelluksia voidaan siirtää pilveen. Nämä jaettiin työssä viiteen kategoriaan: Strategisiin päätöksiin, Migraatioihin ilman muutoksia, Hankintapohjaisiin, Pieniä muutoksia vaativiin ja Suuria muutoksia vaativiin menetelmiin. Monoliittiselle legacy-ohjelmistolle menetelmistä on valittava sellainen, joka sopii oman ohjelmiston tarpeisiin. Menetelmistä kannattaa valita sellainen, jonka avulla saadaan pienellä työmäärällä mahdollisimman paljon pilvipalveluiden tarjoamia hyötyjä. Jos ohjelmistosta halutaan täysin pilvinatiivi, tulisi valita Suuria muutoksia vaativa menetelmä, jossa ohjelmisto refaktoroidaan ja arkkitehtuuri uudistetaan.
Työssä käsiteltävä kohdeohjelmisto modernisoidaan tekemällä konseptitodistus Googlen pilvialustalle Google Kubernetes Engineen. Kubernetes-alusta asettaa vaatimuksia ohjelmistoille, joita sen päällä pyöritetään, jotta Kubernetes-alustasta saataisiin kaikki sen tarjoamat hyödyt. Ensimmäinen vaatimus on tilattomuus, jotta ohjelmistoa voidaan replikoida. Ohjelmiston tulisi olla mikropalveluarkkitehtuuri. Ohjelmiston muuttaminen mikropalveluarkkitehtuuriksi voidaan toteuttaa myös migraation jälkeen.
On myös huomioitava, tukeeko ohjelmisto samasta palvelinprosessista kaikkia asiakkaita vai ovatko prosessit asiakaskohtaisia. Ohjelmistoja voidaan pyörittää Kuberneteksessa asiakaskohtaisesti, mutta kaikkia pilvinatiiviuden tuomia hyötyjä ei saavuteta. Kohdeohjelmisto on tilallinen, monoliittinen ja asiakaskohtainen. Kohdeohjelmiston tapauksessa Kubernetes-alustan hyötyjen saavuttaminen vaatisi suuria refaktorointeja ohjelmiston lähdekoodiin.
Vaikeasti ylläpidettävien monoliittisten legacy-ohjelmistojen ylläpidollisia vaatimuksia voidaan vähentää pilvipalveluiden avulla, ottamalla käyttöön automaatiota sekä ylläpidettyjä komponentteja. Työn kohdeohjelmiston ylläpidettävyyttä parannettiin rakentamalla automaatiota uusien versioiden koontiin, sekä ottamalla käyttöön palveluntarjoajan ylläpitämiä komponentteja itse ylläpidettyjen tilalle, kuten MariaDB-tietokannan korvaaminen CloudSQL-tietokannalla.
Kuberneteksen hyötyjen saavuttamiseksi vaaditun refaktoroinnin määrä kohdeohjelmistoon on suuri ja tämän takia Kubernetes ei tässä vaiheessa ollut oikea alusta ohjelmiston pyörittämiselle pilvessä. Työtä jatketaan vaihtamalla Kubernetes-alusta IaaS-palvelimilla ajettaviin kontteihin niiden ajoon optimoidulla Fedora CoreOS:llä. Työssä suuniteltu pilviarkkitehtuuri voidaan kuitenkin hyödyntää, vaikka ohjelmistoa ajava alusta vaihdetaankin. Pilviarkkitehtuurin muut osat pysyvät samana. Tulevaisuudessa, jos ohjelmisto refaktoroidaan, voidaan tässä työssä suunniteltu pilviarkkitehtuurikin ottaa kokonaisuudessaan käyttöön.
Kirjallisuudessa on esitelty migraatiomenetelmiä, joilla sovelluksia voidaan siirtää pilveen. Nämä jaettiin työssä viiteen kategoriaan: Strategisiin päätöksiin, Migraatioihin ilman muutoksia, Hankintapohjaisiin, Pieniä muutoksia vaativiin ja Suuria muutoksia vaativiin menetelmiin. Monoliittiselle legacy-ohjelmistolle menetelmistä on valittava sellainen, joka sopii oman ohjelmiston tarpeisiin. Menetelmistä kannattaa valita sellainen, jonka avulla saadaan pienellä työmäärällä mahdollisimman paljon pilvipalveluiden tarjoamia hyötyjä. Jos ohjelmistosta halutaan täysin pilvinatiivi, tulisi valita Suuria muutoksia vaativa menetelmä, jossa ohjelmisto refaktoroidaan ja arkkitehtuuri uudistetaan.
Työssä käsiteltävä kohdeohjelmisto modernisoidaan tekemällä konseptitodistus Googlen pilvialustalle Google Kubernetes Engineen. Kubernetes-alusta asettaa vaatimuksia ohjelmistoille, joita sen päällä pyöritetään, jotta Kubernetes-alustasta saataisiin kaikki sen tarjoamat hyödyt. Ensimmäinen vaatimus on tilattomuus, jotta ohjelmistoa voidaan replikoida. Ohjelmiston tulisi olla mikropalveluarkkitehtuuri. Ohjelmiston muuttaminen mikropalveluarkkitehtuuriksi voidaan toteuttaa myös migraation jälkeen.
On myös huomioitava, tukeeko ohjelmisto samasta palvelinprosessista kaikkia asiakkaita vai ovatko prosessit asiakaskohtaisia. Ohjelmistoja voidaan pyörittää Kuberneteksessa asiakaskohtaisesti, mutta kaikkia pilvinatiiviuden tuomia hyötyjä ei saavuteta. Kohdeohjelmisto on tilallinen, monoliittinen ja asiakaskohtainen. Kohdeohjelmiston tapauksessa Kubernetes-alustan hyötyjen saavuttaminen vaatisi suuria refaktorointeja ohjelmiston lähdekoodiin.
Vaikeasti ylläpidettävien monoliittisten legacy-ohjelmistojen ylläpidollisia vaatimuksia voidaan vähentää pilvipalveluiden avulla, ottamalla käyttöön automaatiota sekä ylläpidettyjä komponentteja. Työn kohdeohjelmiston ylläpidettävyyttä parannettiin rakentamalla automaatiota uusien versioiden koontiin, sekä ottamalla käyttöön palveluntarjoajan ylläpitämiä komponentteja itse ylläpidettyjen tilalle, kuten MariaDB-tietokannan korvaaminen CloudSQL-tietokannalla.
Kuberneteksen hyötyjen saavuttamiseksi vaaditun refaktoroinnin määrä kohdeohjelmistoon on suuri ja tämän takia Kubernetes ei tässä vaiheessa ollut oikea alusta ohjelmiston pyörittämiselle pilvessä. Työtä jatketaan vaihtamalla Kubernetes-alusta IaaS-palvelimilla ajettaviin kontteihin niiden ajoon optimoidulla Fedora CoreOS:llä. Työssä suuniteltu pilviarkkitehtuuri voidaan kuitenkin hyödyntää, vaikka ohjelmistoa ajava alusta vaihdetaankin. Pilviarkkitehtuurin muut osat pysyvät samana. Tulevaisuudessa, jos ohjelmisto refaktoroidaan, voidaan tässä työssä suunniteltu pilviarkkitehtuurikin ottaa kokonaisuudessaan käyttöön.