Kjøre PHP i App Engine Standard-miljø i 2019

Jeg er tilhenger av å bruke «kjedelig» (eller «moden», som jeg liker å kalle det) teknologi til kundearbeid. Jeg liker å bruke kjente, veldokumenterte verktøy til å løse kundeproblemer. For meg dreier jobben seg i all hovedsak om å implementere kundens forretningsløsninger. Så da jeg begynte å bruke Google Cloud Platform, hadde jeg regnet med at jeg bare skulle fortsette å kjøre koden min på virtuelle Linux-maskiner, og at det eneste dette ville innebære, var at VM-ene befant seg på et annet sted – og angivelig ville være sikrere, lettere å sikkerhetskopiere og kanskje ha bedre SLA. Tidligere hadde jeg eksperimentert med containerbruk med Docker Swarm og deretter Kubenetes (til tross for at jeg foretrekker å bruke moden teknologi, følger vi den teknologiske utviklingen på produksjonssiden – for noen av dagens nyvinninger kommer jo en dag til å bli morgendagens «kjedelige»). Men jeg hadde kommet til den konklusjonen at containerløsninger fremdeles var en flaskehals hvor vinninga gikk opp i spinninga.

Men da The Cloud People fikk vind i seilene som GCP-partner og jeg begynte å ta sertifiseringer, fikk jeg gode muligheter til å studere og leke meg med de ulike GCP-alternativene for kjøring av containerbaserte programmer. Det er en rekke ulike alternativer som fungerer godt for ulike bruksområder. For eksempel bruker vi Kubernetes til å kjøre noen programmer, noe vi har hatt glimrende erfaring med. Men alternativet som stakk seg ut, var App Engine Standard-miljøet. Det lovet en virkelig «No-Op»-opplevelse og sømløs skalering … og så oppdaget jeg kjøretidskravene. Spesifikke versjoner for spesifikke språk med begrensede biblioteker – det virket begrensende. Jeg ristet på hodet og gikk tilbake til mine Linux VM-er. Men så kom det noen nye kjøretider. Den nye PHP-kjøretiden støtter installasjon av arbitrære biblioteker via composer! Det så ut som noe jeg ville prøve! Vi hoppet inn med en rekke nye tjenester.

Hva har vi gjort, og hvordan har erfaringen vært?

• Personlig ville jeg foretrukket å bruke Python, mens noen av kollegaene mine ville brukt Go, men siden flere av oss har mye kunnskap om PHP (og språket har blitt mye bedre i løpet av det siste tiåret), bestemte vi oss for å fortsette med PHP.
• Vi bestemte oss tidlig for å støtte lokal utvikling med en «docker/docker-compose». Det viste seg å være en veldig god beslutning, for det betyr at vi ikke er låst til App Engine. Vi vet at koden vår kan kjøres i andre miljøer enn GCP.
• Det er nesten for lett å distribuere rett til testforekomster i GCP! Til produksjonen har vi begynt å låse på plass distribusjonsprosessen.
• Det skrivebeskyttede filsystemet har vært en liten begrensning, men det har tilrettelagt for bestepraksiser rundt build-artefakter og mediafiler.
• Vi bruker et «Full-fat»-rammeverk som vi er veldig godt kjent med. De fleste funksjonene i rammeverket fungerer perfekt. Enkelte funksjoner er begrenset av det skrivebeskyttede filsystemet. Én dag vil vi prøve å løse noen av utfordringene knyttet til dette, men vi har ikke hatt noen problemer med det ennå.
• Build-tjenesten for App Engine støtter ikke etterinstallering av skript for composer. Det har vært den største begrensningen vi har støtt på så langt.
• Integrering med andre GCP-tjenester har gått strålende.
• I disse prosjektene bruker vi allerede i stor grad Pub/Sub, postgres driftet i Google Cloud SQL og Google Cloud Storage. I fremtiden vil noen av oppgavene som er egnet for Cloud Functions, bli refaktorert i Cloud Functions.
• Så langt har kostnadene (rimelige), den automatiske skaleringen (sømløs) osv. vært akkurat som forventet.
• Vi planlegger nå å migrere noen eldre produkter til App Engine Standard-miljøet.

Har du noen spørsmål, er det bare å ta kontakt!