Da SaaS-en ble for dyr: slik bygde vi egen deploy og overvåking

Vi brukte selv en betalt driftsplattform til deploy og overvåking av serverne våre. Da vi kartla hva den faktisk gjorde, lå nesten alt som vanlig Ubuntu-konfigurasjon på serveren. Plattformen sto for deploy-triggeren og helsesjekken, resten var vårt eget oppsett. Den svakeste delen av slike plattformer er gjerne varslingen: e-post til en postkasse ingen sjekker. Kommer nedetiden da, har du verken varsel, historikk eller noe klart bilde av hva som skjedde.

Hvorfor blir vi låst til SaaS-drift?

Mange velger betalte driftsplattformer fordi de tror de trenger «fullstendig automatisering» eller «enterprise-grade overvåkning». Som regel er det to enklere grunner. Den ene er at oppsettet er lett: koble til, trykk på, så kjører det. Den andre er frykten for å gjøre det feil, tanken om at man må lære alt fra bunnen av hvis man prøver selv.

Det meste av det plattformen gjør, kan du sette opp på en Ubuntu-server med vanlige verktøy. Da eier du både oppsettet og innsikten i hva som skjer.

Hva gjør en typisk driftsplattform?

En betalt tjeneste gjør tre ting. Den utløser deploy: når du pusher kode, skal den bygge, teste og flytte ut til produksjon. Den kjører helsesjekk og måler om tjenesten svarer, om ressursene er i orden og om avhengighetene er tilgjengelige. Og den varsler når noe går galt, i tide og på riktig kanal. Alt dette kan du bygge med åpen kildekode som allerede ligger i pakkelageret til serveren din.

Hva er egentlig avhengigheten?

Før du tenker på å bytte, må du kartlegge hvor mye av arbeidsflyten din som faktisk går gjennom SaaS-en. Tre spørsmål du bør svare ærlig på:

• Kjører du deploy via CLI eller API? Trykker du bare «Deploy» i webgrensesnittet, er du låst. Har du et skript som kjører git pull og systemctl restart, er du allerede halvveis.
• Hvordan får du varsling? E-post, Slack eller SMS? Går det gjennom et enkelt webhook-kall, kan du bytte mottaker uten å endre noe i koden din.
• Hvor ligger konfigurasjonen? I Git, eller i et GUI på en ekstern server? Må du logge inn et sted for å endre én variabel, er du sårbar.

Skill mellom verktøy og prosess. SaaS-plattformer bytter gjerne ut din egen prosess med sin, og da er du avhengig av både verktøyet og måten leverandøren tenker på.

Hvordan flytte over, trinn for trinn

Ikke bytt alt på en gang, og ikke slett noe før du vet at det nye virker.

1. Skriv ned nøyaktig hva SaaS-en gjør nå: hvilke skript, hvilke miljøvariabler, hvilke webhook-mottakere og hvilke varslingskanaler.
2. Sett opp en testserver med samme Ubuntu-versjon. Bygg samme deploy-flyt med bash, make eller Ansible. Kjør tjenestene under systemd og bruk prometheus-node-exporter til helsesjekk.
3. Kjør deploy mot testmiljøet. Sjekk at helsesjekkene svarer og at varslene kommer fram dit de skal. Ikke gå videre før alt stemmer.
4. Flytt produksjonen når testen er god. La SaaS-en stå i en uke eller to som reserve, men ikke bruk den.

For et vanlig prosjekt tar dette to til fem dager.

Hva du bør bruke i stedet

En stack som fungerer på en vanlig Ubuntu-server:

• Deploy gjør du med git, systemd og et enkelt deploy.sh-skript. Ansible kan du legge til senere hvis du trenger mer orkestrering.
• Helsesjekk får du fra prometheus-node-exporter for systemdata og prometheus-blackbox-exporter for HTTP- og TCP-sjekk. Begge installeres med apt.
• Varsling går gjennom prometheus-alertmanager og webhookd, eller et direkte curl-kall mot Slack, Teams eller Discord. Vil du ha e-post, holder mailutils.
• Historikk ligger i journalctl og logrotate. Trenger du dashboard, kan du legge til Loki, men det er valgfritt.

Alt dette er gratis og åpen kildekode, og du eier hele oppsettet. Ingen abonnement, og ingen som plutselig setter opp prisen eller krever enterprise-lisens for å bruke webhook.

Hva du bør sjekke nå

Ikke vent på krisen. Bruk en time i dag på disse fire:

• Deploy-triggeren: er den et API-kall du kan gjenskape med curl? Hvis ikke, lag et lite skript som gjør det samme.
• Helsesjekkene: har du et enkelt HTTP-endepunkt du kan spørre? Hvis ikke, lag ett med Flask eller FastAPI på ti linjer.
• Varslingen: hvor havner meldingene? I en postkasse ingen sjekker, eller i en Slack-kanal ingen svarer i? Flytt dem til en kanal du faktisk ser.
• Tilgangen: kan du logge inn nå? Ligger passordet i en notis? Er tofaktor på? Mister du tilgangen i morgen, er du ute av spill.

Du kan allerede sette opp en server. Det som gjenstår er å ta kontrollen tilbake.

Trenger du hjelp til å kartlegge hva du faktisk trenger, og til å bytte uten å miste tid eller stabilitet? Ta kontakt.