Vi har alle hørt om konseptet å «flytte til skyen», men mange syns fremdeles at konseptet å flytte data fra stasjonære servere og driftssentre til «skyen» virker skremmende. I denne artikkelen vil jeg gi litt innsikt i hvordan dette kan gjøres og hvordan vi gjorde dette for en av våre applikasjoner, en Legacy Monolithic CMS-applikasjon som bruker PHP og Laravel og benytter en PostgreSQL-database. Denne applikasjonen har blitt brukt som rammeverk for å levere flere kundeprosjekter av varierende kompleksitet med flere integrasjoner mot tredjepartstjenester, og inneholder mange tusen linjer med kode.

Vi startet med å undersøke hvilke fordeler vi ville få av å flytte applikasjonen inn i skyen, og hvilke mulige utfordringer vi kunne støte på underveis. Vi evaluerte forskjellige alternativer; fra bare et «lift and shift» ved å utnytte ulike GCP-verktøyer, til å konvertere applikasjonen til å bli helt cloud-native. Vi bestemte oss for kun å gjøre små endringer i selve applikasjonen og bare gjøre noen mindre strukturelle justeringer.

For å kunne utnytte Google Cloud SQL som databaseserver i stedet for den lokale postgreSQL-serveren måtte vi oppgradere databasen til ny versjon, og vi frigjorde oss på denne måten fra driften av databaseserveren. Google Cloud SQL er en skydatabase som en tjeneste på Google Cloud Platform som støtter både MySQL og PostgreSQL. Noen av funksjonene og utvidelsene vi brukte støttes ikke på Google Cloud SQL, og disse måtte derfor omskrives til et støttet standardspråk. Med Postgres’ nyeste versjon og inkluderte funksjonaliteter var dette en grei jobb.

Etter å ha vurdert hvilke konsekvenser et skifte fra lokal drift til «skyen» ville ha var det ikke store justeringene vi var nødt til å gjøre. Endringer i databasen for å støtte Google Cloud SQL og justeringer i mail-routingen for å utnytte Mailgun for å sende e-post fra Google Cloud Platform var to av de. Utsendelse av e-post fra Google Cloud Platform på port 25 er ikke mulig da denne porten alltid er blokkert på GCP. Vi så også noen mulige fremtidige forbedringer i å splitte applikasjonen i microservices, utnytte Google Cloud Load Balancer og flytte applikasjonen til et Kubernetes Cluster, men dette var ikke innenfor rammene av dette prosjektet.

Vi bestemte oss for å gjøre et «lift and shift» fra nåværende VM til Google Cloud Compute Engine, som kort sagt betyr replikering av VM (inkludert noen nødvendige endringer i nettverkskonfigurasjon). Vi flyttet deretter databasene til Cloud SQL. «Lift and shift» ble gjennomført og utført uten problemer, og vi kunne starte vår Sites CMS-applikasjon på GCP for testing i løpet av bare noen timer ved å benytte den lokale postgreSQL databaseserveren, som ligger på det samme VM’et. Vi gjorde endringer i konfigurasjonene slik at vi kunne benytte Mailgun, utførte tester på CMS, drift-test av sidene og testet ytelsen på applikasjonen.

Med alle testene og de første konfigurasjonene på plass, forberedte vi postgreSQL-databasen for overføring til Google Cloud SQL. Vi omskrev de SQL-funksjonene vi trengte, opprettet vår Google Cloud SQL-instans og importerte databasen. Etter å ha konfigurert de nødvendige sikkerhetsinnstillingene for å autorisere at applikasjonen kunne kommunisere med Google Cloud SQL-instansen startet vi testing av hele løsningen – en av våre dev-sites ble første prøveprosjekt. Etter intensiv testing av funksjonaliteten bestemte vi oss for å flytte våre developer sites til Google Cloud Platform, for deretter også å flytte production sites etter at verifiseringen av et vellykket dev-flytt ble bekreftet.

Gradvis flyttet vi løsningene, en etter en, inn på GCP-løsningen, uten nedetid. Det eneste som ble berørt var artikler som ble publisert i mellomtiden, og som måtte publiseres på nytt. Dette var en avgjørelse tatt på et kost/nytte-grunnlag – om nødvendig kunne vi flyttet løsningen helt uten nedetid.

Vi gikk fra å ha seks servere for nettsider (fra dev til prod), til å bare ha to Google Cloud-servere og to Google Cloud SQL-instanser. Siden dette flyttet har utviklere begynt å benytte Cloud native-funksjoner som Pub Sub i applikasjoner. Med Google Cloud Platform er sikkerheten garantert høy, og alle data kryptert.

Denne applikasjonen er en av en rekke legacy applikasjoner vi har flyttet fra driftssentre til forskjellige GCP-miljøer, inkludert Kubernetes og Google Compute Engine. Vi har også implementert Cloud Native-applikasjoner ved hjelp av Kubernetes og Google App Engine.

Har du spørsmål om hva et skifte til Google Cloud Platform kan gjøre for deg og din bedrift? Kontakt oss.