IT-palveluita modernisoidessa yli 10 vuotta vanhat PHP-hankkeet ovat lähellä sydäntäni. Olen nimittäin itse ollut aikanaan tekemässä kyseisiä hankkeita ja sittemmin modernisoimassa niitä. PHP on teknologia, jolla moni liiketoiminta on päässyt liikkeelle ja joka on mahdollistanut valtavan kirjon erilaisia toteutuksia, mutta toisaalta sillä on luotu mitä ihmeellisempiä riesoja.
PHP-projekteja on maailmassa paljon. Valtaosaa yhdistää se, että ne on aloitettu alun perin useita vuosia sitten. En ole nähnyt ainakaan omassa kuplassani uutukaisia PHP-projekteja vuosikausiin. Kuten minkä tahansa softahankkeen tai teknologian kanssa vuosikymmen on pitkä aika. Siinä ajassa kertyy monenlaista velkaa: teknistä ja suunnitteluvelkaa sekä tarpeita, jotka palvelu jättää täyttämättä. Maailma on myös muuttunut. Riippumatta teknologiavalinnasta moni projekti muuttuu riesaksi. Riesaksi, jonka rajoitteet kaikki tunnistavat, mutta jota on vaikea korvata.
Voit lukea aiemmasta blogikirjoituksestani, kuinka palvelun modernisoinnille luodaan strategia. Tarkastelen seuraavaksi PHP-hankkeille ominaisia modernisoinnin piirteitä, ja käytän samaa lähestymistapaa kuin edellä mainitussa kirjoituksessa – eli kolmea vaihetta, kuinka lähestyä modernisointihanketta:
- Kerää tietoa ja analysoi
- Määritä tavoitteet
- Tee valintoja ja luo toimenpiteet
Mistä siis lähteä liikkeelle? Mitkä ovat PHP:n modernisoinissa määrittelevät kysymykset, jotka vaikuttavat eniten lopputulemaan? Näiden vaiheiden kautta ne selviävät.
Kerää tietoa
Mitä PHP-projektin modernisoinnissa tulee erityisesti ottaa huomioon? Tavoitteeseen päästään vain nykytilanteesta.
Pohdi näitä PHP-spesifejä teknologiakysymyksiä:
- Onko nykyisessä projektissa oleva esityskerros vielä jokin vanhan liiton PHP template enginen generoima?
- Onko frontend jo irrallinen, ja PHP tarjoaa API:n?
- Ovatko PHP-versio ja kaikki toiminnallisuudet ajan tasalla?
- Onko käytössä jokin PHP-framework ja onko sille tuki tai onko se aktiivisessa kehityksessä?
- Täytyykö PHP-versio ja -framework päivittää tai vaihtaa kokonaan uuteen? Voiko tämän tehdä osissa?
- Minkälaisia palvelin-, palvelu- tai verkkotarpeita on olemassa? Ajetaanko PHP:tä pilvessä, ja onko tarvetta arkkitehtuurin modernisoinnille?
Teknologiakysymyksiä ja tulevaisuuden tarpeita tulee tarkastella myös laaja-alaisemmin. Pohdi ainakin näitä kysymyksiä modernisointiprojektia suunnitellessa:
- Onko nykyisellä tiimillä valmiuksia ja halua ottaa haltuun uusia ohjelmointikieliä, arkkitehtuuriparadigmoja tai erilaisia työtapoja? Kuinka paljon selaimessa tapahtuvaa interaktiivisuutta palvelu tarvitsee ja tiimi osaa?
- Luodaanko frontend jatkossa modernilla komponenttipohjaisella ratkaisulla, kuten Reactilla? Dedikoidaanko frontendin ja/tai mobiiliapplikaation rakentamiseen erillinen tiimi?
- Olisiko palvelun arkkitehtuuri ja infrastruktuuri kätevää uudistaa samalla? Otetaanko käyttöön event-pohjainen arkkitehtuuri, viestijonoja tai Dockerit, Kubernetekset ja muut modernit työkalut, esimerkiksi laadunvarmistuksen ja tuotantoonvientien sujuvoittamiseksi?
Näihin kysymyksiin kannattaa vastata huolella, jotta modernisointihankkeen lopputulema ei ole sama kuin mistä aloitettiin. Monta PHP-hanketta ja uudistusta nähnyt kumppani voi auttaa kysymyspatteriston käsittelyssä.
Yksi merkittävä linjaus on modernisaation teknologiavalinta, ja mainittakoon heti, että se voi edelleen olla PHP. Olemme todistaneet, että PHP kestää aikaa, sillä iso osa internetistä pyörii edelleen PHP:n päällä. Tärkeämpää on miettiä bisneksen tavoitteita nyt ja pitkälle tulevaisuuteen.
Määritä tavoitteet
Aloita miettimällä tavoitetta. Onko tavoitteena:
- Päästä PHP:stä kokonaa eroon?
- Järkevöittää koodipohja ja mahdollistaa sujuvampi jatkokehitys PHP:lla?
- Irrottaa backend ja frontend toisistaan tai modernisoida arkkitehtuuria laajemmin?
- Luoda puitteet mobiilisoftan olemassaololle?
Pohdi bisneskysymyksiä, eli mitä liiketoiminnan tavoitteita uudistuksella tavoitellaan:
- Tavoitellaanko kehityksen nopeuttamista ja muutoskyvykkyyden parantamista?
- Tavoitellaanko kehityksen siirtämistä tai pitämistä oman yrityksen sisällä? Minkälaiselta tulevaisuuden rekrymarkkina näyttää?
- Tavoitellaanko jakokehityksen, ylläpidon tai muiden juoksevien kustannusten minimoimista?
- Tavoitellaanko kehitystiimin ja tuoteomistajan arjen helpottamista?
- Tavoitellaanko Green ICT -hengessä planeetalle kevyttä kustannustehokasta ratkaisua?
Nykytilanteesta tulevaisuuteen päästään linjausten ja toimenpiteiden kautta, ja tästä kokonaisuudesta syntyy modernisoinnin strategia.
Tee valintoja
Valinnat, erityisesti teknologian näkökulmasta, vaikuttavat kaikkeen tulevaisuuden jatkokehittämiseen, joten ne tulee tehdä huolella. Alla muutamia tavanomaisia linjauksia ja esimerkkivalintoja, joita modernisointiprojektissa pitää tehdä ja huomioida.
Aikaa kestävä teknologia
Tylsä teknologia ei välttämättä houkuttele tuoreimpia tutkijoita ja hifistelijöitä projektisi ääreen, mutta se mahdollistaa hankkeesi jatkuvuuden. Tylsä teknologia voi olla PHP, Java, ja nykyään myös Node. Vuonna 2024 PHP:tä suositumpi stacki on esimerkiksi React ja Node.js, joita tehdään JavaScriptillä tai sen jämptimmällä isoveljellä TypeScriptillä.
Oli käytössä mikä tahansa kieli tai framework, kannattaa valittujen kirjastojen ja ajoympäristöjen versiopäivitykset pitää ajan tasalla pelkästään tietoturvan takia. Versiopäivitykset myös optimoivat esimerkiksi ajonopeutta tai tuovat sovelluskehitystä helpottavia ja ohjelmointikieltä parantavia toiminnallisuuksia käyttöön.
Mitä yleisempi valittu teknologia on, sitä helpompi on löytää sen teknologian osaajia. Sitä helpompi on myös tarvittaessa löytää uusi toimittaja jatkamaan kehitystyötä. Toimittajariippumattomuuden saavuttamiseksi täytyy teknologiavalintojen lisäksi varautua tulevaisuuteen järkevillä arkkitehtuurisilla valinnoilla.
Monoliitistä mikropalveluihin
Palvelujen arkkitehtuuri voidaan karkeasti jakaa kahteen tyyppiin: yhtenäiseen eli monoliittiseen ja eroteltuun eli mikropalveluakkitehtuuriin.
Monoliitti tarkoittaa yhtä ainoaa koodipohjaa, joka asennetaan kerralla ja jota ajetaan kokonaisuudessaan samanaikaisesti. Monoliitin sisällä voi toki olla järkevää arkkitehtuuria; se ei tarkoita yhtä solmussa olevaa tiedostoa tai ole itseisarvoisesti huono asia.
Mikropalvelu tarkoittaa jotain pientä, yleensä yhtä käyttötarkoitusta varten rakennettua palvelua, kuten esimerkiksi maksamista, ajanvarausta tai käyttäjähallintaa. Lopullinen käyttäjälle suunnattu palvelu käyttää konepellin alla näitä mikropalveluita aina silloin kun on tarve. Mikropalveluita voidaan rakentaa millä tahansa käyttötarkoitukseen sopivalla alustalla tai ohjelmointikielellä, ja täten laajentaa kehittävän tiimin osaamista tai rekrymahdollisuuksia. Koska mikropalvelut ovat nimensä mukaisesti pieniä, on niiden ylläpito ja jatkokehitys yksinkertaisempaa, sillä koodipohjan keskinäisempiä regressiobugeja aiheuttavia riippuvuuksia on vähemmän.
Mikropalvelut eivät kuitenkaan aina ole paras ratkaisu. Ne tuovat mukanaan kompleksisuutta ja joissain tapauksissa latenssia eli viivettä. Usean mikropalvelun rutiininomaiset toimet, kuten versiopäivitykset tai infrastruktuurin huolto vievät mahdollisesti enemmän aikaa. Myös hyvin suunniteltu ja huollettu monoliitti voi olla liiketoiminnallisesti tehokas ja paras ratkaisu.
Frontend ja backend eli sovelluslogiikan jako kerroksiin
Moni vanha projekti pohjautuu tapaan rakentaa koko palvelu toiminnallisuuksineen toimimaan palvelimen päässä niin, että palvelun bisneslogiikan ja esityslogiikan välissä ei ole abstraktiokerrosta, joka mahdollistaisi niiden päivittämisen erikseen eri työkaluilla.
Nykyään kokonaisuudet ovat yleensä jaoteltu kahteen tasoon: frontendiin ja backendiin. Backendissa, palvelinpuolella tapahtuu niin datan hallinta, tietokantojen käsittely kuin integraatiot toisiin järjestelmiin sekä koko palvelun toiminta- ja bisneslogiikka. Frontend eli selainpuoli on osa, jonka käyttäjät näkevät. Sen osana on käyttöliittymä, selaimessa tapahtuvat toiminnallisuudet ja koko esityslogiikka eli miten sovelluksen tiedot ja toiminnot käyttäjille esitetään.
Backend ja frontend kannattaa lähtökohtaisesti nykypäivänä erottaa toisistaan. Tämä mahdollistaa selkeämmän jaottelun palvelun vastuiden välillä ja esimerkiksi mahdollisuuden rakentaa mobiiliapplikaatio, joka on käytännössä toinen erillinen frontend. On olemassa myös tapauksia, joissa erottelu ei ole perusteltavissa, vaan liiketoiminta pärjää yksinkertaisemmalla ratkaisulla.
Modernisointiprojektissa backendin ja frontendin erottaminen kannattaa usein tehdä osissa. Esimerkkinä backendiin voidaan rakentaa PHP:lla REST API, jonka päälle rakennetaan erillinen frontend, yleensä Reactilla tai vastaavalla modernilla komponenttipohjaisella frameworkilla. Tämä vaatii tietysti uutta osaamista ja erilaista suhtautumista koko kehitystyöhön, mikäli ajattelu ei ole tuttua. Jako kahteen tasoon aloitetaan useimmiten palvelun loppuasiakasrajapintaan suuntautuvista alueista, joissa käyttökokemuksen parantamisesta on eniten hyötyä.
Kohti modernia PHP-ympäristöä ja tehokasta liiketoimintaa
PHP-hankkeen modernisointi on monitahoinen prosessi, joka edellyttää selkeän liiketoiminnallisen tavoitteen määrittelyä ja strategista suunnittelua. Se tarjoaa mahdollisuuden päivittää teknologiaa, parantaa prosesseja ja mahdollisesti nykyaikaistaa käyttökokemusta.
Nykyaikainen PHP voi edelleen olla keskeisessä roolissa, kunhan se integroidaan osaksi järkevästi suunniteltua kokonaisarkkitehtuuria. Moderni arkkitehtuuri ja selkeä koodipohja mahdollistaa kehittämisen joustavuuden ja paremman kyvykkyyden reagoida yllättäviin liiketoiminnan tarpeiden muutoksiin. Onnistunut modernisointi vaatii tiimin osaamisen kehittämistä ja todennäköisesti uusien teknologioiden hyödyntämistä, jotta tuoteorganisaatio voi vastata tulevaisuuden haasteisiin.
Älä jää yksin näiden valintojen kanssa, vaan kysy apua kokeneelta kumppanilta. Fraktiolla autamme vastaamaan niin teknisiin valintoihin kuin kasvattamaan yritysten omaa ymmärrystä ja kykyä jatkokehittää itse palveluitaan. Lue enemmän valmentavasta toimintatavastamme aiemmasta kirjoituksestani.
