Har vi gjort programvareutvikling altfor komplisert?
En nostalgisk reise fra FTP-cowboyer til Kubernetes-kaos
Husker du 1999? Mens resten av verden forberedte seg på Y2K-apokalypsen, satt vi webutviklere og levde vårt beste liv. Deployment? Det tok fem sekunder. Åpne FileZilla, dra PHP-filen over til serveren, ferdig. I dag? Vel, la meg først sjekke om GitHub Actions pipeline har grønt lys, om Docker-imaget bygger riktig, om Kubernetes-clusteret har nok ressurser, om Terraform state-filen er synkronisert, om... vent, hva var det jeg skulle deploye igjen?
Da deployment var en dragondrop-affære
La oss ta en tidsmaskin tilbake til slutten av 90-tallet. En typisk webapplikasjon besto av noen få ingredienser: PHP, MySQL, og Apache - den hellige LAMP-stacken. Prosjektstrukturen var så enkel at selv sjefen kunne forstå den:
nettside/
├── index.php
├── om-oss.php
├── kontakt.php
├── bilder/
│ └── [masse GIF-er fra Photoshop-slicing]
└── kanskje-en-css-fil-hvis-du-var-fancy.css
Deployment-prosessen anno 1999:
- Rediger PHP-filen lokalt
- Trykk Ctrl+U i HomeSite (for de som husker den)
- Filen er live på produksjon
- Test direkte i prod ved å refreshe browseren
Total tid: 5-30 sekunder, avhengig av om du hadde 56k modem eller ISDN.
En veteran-utvikler forteller: "Jeg hadde editoren konfigurert med en hurtigtast for FTP-opplasting. Det var glorieverdige tider. Jeg hadde teknisk sett null nedetid på deployments i 2002, og alt jeg trengte å gjøre var å flytte en fil til serveren."
Moderne deployment: en kafka-esk prosess
Spol frem til 2024. La oss si du skal deploye samme enkle kontaktskjema:
Steg 1-47 i moderne deployment:
- Commit koden til feature branch
- Åpne pull request
- Vent på at 15 forskjellige CI/CD-jobber skal kjøre
- GitHub Actions bygger Docker-imaget
- Security scanning (SAST, DAST, IAST - alle -AST'ene)
- Unit tests, integration tests, E2E tests
- SonarQube sjekker kodekvalitet
- Dependabot advarer om 47 sårbarheter i dependencies
- Merge til main (etter code review fra 3 kollegaer)
- Deploy til staging-miljø
- Kjør smoke tests
- Deploy til pre-prod
- Kjør regresjonstester
- Oppdater Kubernetes manifester (8-15 YAML-filer)
- Apply Helm charts
- Vent på at pods starter
- Health checks må bli grønne
- Deploy til produksjon med blue-green strategy
- Monitor Grafana dashboards
- Sjekk Datadog for anomalier ...
Total tid: 2 timer til 3 dager, hvis alt går bra.
Hello World har blitt Hello Complexity
1999:
<html>
<body>Hei verden!</body>
</html>
Antall filer: 1
Dependencies: 0
Build-tid: N/A (hvilken build?)
2024:
npx create-react-app min-app
Antall filer: ~35,000
Dependencies: 281+ npm-pakker
node_modules størrelse: 250MB
Build-tid: 2-5 minutter
For å vise "Hei verden!" på skjermen.
Tallenes tale: hvor mye tid bruker vi egentlig på koding?
Her kommer den virkelig deprimerende statistikken fra 2024:
- 16% - Så lite av arbeidstiden bruker moderne utviklere faktisk på å skrive kode
- 62% av utviklere rapporterer at teknisk gjeld er deres største frustrasjon
- 25-30 forskjellige verktøy bruker gjennomsnittsutvikleren aktivt
- 2-3 timer per uke går med til å bytte mellom verktøy
- 83% av utviklere må nå også være DevOps-ingeniører
En utvikler fra Reddit oppsummerer det perfekt: "All denne skalerings- og arkitektur-tullet eksisterer bare så mellommanns-selskaper har noe å selge."
PHP-cowboyenes gyldne æra
"Jeg var en PHP-cowboy," forteller en utvikler nostalgisk. "Gjennom årene skrev jeg over 300,000 linjer PHP, og alle applikasjonene mine krevde ikke mer enn PHP 4.x standardbiblioteket. Jeg har disse monstrøse 7,500+ linjers PHP-filene som har en blanding av PHP, HTML, SQL og JavaScript."
Høres forferdelig ut? Kanskje. Men her kommer twisten: "En gammel side for en av kundene mine kjører fortsatt etter 11 år, og han har generert over $700,000 i inntekter med et custom PHP CRM-system. Alt kjører på en shared hosting-leverandør som koster $7 i måneden, og jeg har ikke engang logget inn på kontrollpanelet på 8 år."
$7 i måneden. 8 år uten vedlikehold. $700,000 i inntekter.
Sammenlign det med dagens enterprise Kubernetes-cluster som krever et dedikert platform-team bare for å holde det gående.
Sikkerhet? Hva er det?
Ok, la oss være ærlige. 1999 var også tiden da:
- Passord ble lagret i plain text
- SQL injection var så vanlig at det nesten var en feature
- "Sikkerhet gjennom obskuritet" var en legitim strategi
- SSL-sertifikater kostet tusenvis av kroner
En utvikler husker: "Vi hadde bokstavelig talt admin.php liggende åpent på nettet med hardkodet passord i kildekoden."
Så ja, moderne sikkerhetspraksis er definitivt en forbedring. Men trengte vi virkelig 15 forskjellige security scanning-verktøy i CI/CD-pipelinen?
JavaScript-økosystemets eksplosjon
La oss snakke om npm, skal vi?
2024 statistikk:
- 800,000+ pakker i npm registry
- 1,800+ JavaScript frameworks og biblioteker aktivt vedlikeholdt
- 300-500 dependencies i et gjennomsnittlig moderne webprosjekt
- 50-200MB node_modules for et "Hello World"-prosjekt
En favoritt-meme fra 2024 viser moderne programvareutvikling som en stabel med adaptere oppå hverandre - "Den absolutte TRAGEDIEN med moderne programvareutvikling... å bruke en serie adaptere stablet oppå hverandre bare for å plugge noe inn!"
Microservices: når 1 blir til 100
1999: En PHP-fil håndterer alt
2024: 100 microservices for et team på 20 utviklere
Sant eksempel fra virkeligheten: Et selskap implementerte microservices-arkitektur og endte opp med å administrere 2,200+ tjenester. Uber, for eksempel, har over 2,200 microservices. For hver nye feature må du nå:
- Oppdatere 5-10 forskjellige tjenester
- Koordinere deployments
- Håndtere inter-service kommunikasjon
- Debugge distribuerte systemer (lykke til!)
Men vent, det er ikke alt svart-hvitt
La oss være fair. Moderne verktøy løser reelle problemer:
Skalerbarhet: Dagens frameworks kan håndtere millioner av brukere. I 1999 krasjet serveren hvis lokalavisen linket til siden din.
Samarbeid: Git, code reviews, og CI/CD gjør det mulig for store team å jobbe sammen. I 1999 sendte vi ZIP-filer på e-post.
Brukeropplevelse: Single-page applications, real-time updates, og responsive design var science fiction i 1999.
Global distribusjon: CDN-er, edge computing, og serverless lar oss serve brukere over hele verden med minimal latency.
Tilbake til fremtiden: enklere tider på horisonten?
Det finnes håp! Flere bevegelser forsøker å forenkle moderne webutvikling:
JAMstack-renessansen: Selv Matt Biilmann (Netlify CEO) har bedt om at JAMstack skal "miste kompleksitet og bli enkel igjen."
No-build bevegelsen: Verktøy som Vite fokuserer på utviklingshastighet over build-optimalisering.
Serverless: Eliminer infrastruktur-hodepine (men introduser vendor lock-in hodepine).
AI-assistenter: La GitHub Copilot skrive boilerplate-koden og konfigurasjonsfilene.
Konklusjonen ingen tør si høyt
Sannheten er at vi har bygget et absurd komplekst økosystem for å løse problemer som de fleste av oss ikke har. En typisk bedriftsapplikasjon i dag krever:
- 15-25 forskjellige CI/CD-verktøy
- 8-15 Kubernetes YAML-filer for en enkel deployment
- 200-500+ Terraform-konfigurasjonfiler
- 300-500 npm dependencies
Alt dette for applikasjoner som fundamentalt sett gjør det samme som de 7,500-linjers PHP-filene gjorde i 1999: CRUD-operasjoner mot en database.
Veien videre
Kanskje løsningen ikke er å gå tilbake til FTP og PHP 4 (selv om det var gøy). Kanskje løsningen er å innse at ikke hver applikasjon trenger:
- Microservices arkitektur
- Kubernetes orchestration
- Multi-stage Docker builds
- 47 forskjellige monitoring-verktøy
- En dedikert SRE-team
Noen ganger er en boring Ruby on Rails monolitt på Heroku akkurat det du trenger. Noen ganger er en NextJS-app på Vercel perfekt. Og noen ganger - bare noen ganger - er kanskje til og med en god gammel PHP-fil på shared hosting den rette løsningen.
Som en klok utvikler sa: "Jeg var en lykkeligere utvikler den gangen, fordi jeg ikke brydde meg om annet enn å skrive kode. I dag bruker jeg 84% av tiden min på alt annet."
Så neste gang du sitter fast i YAML-helvete og prøver å debugge hvorfor Kubernetes-poden din ikke starter, husk: en gang i tiden tok deployment 5 sekunder, og det fungerte faktisk helt fint.
Epilog: Denne artikkelen ble skrevet mens jeg ventet på at CI/CD-pipelinen min skulle bli ferdig. Den har kjørt i 47 minutter nå. I 1999 hadde jeg allerede deployert 15 ganger og tatt en lang lunsj.
