Hosted sau self-hosted pentru un proiect de client: cum decizi

Un client cere un instrument intern sau un portal care va ține evidența clienților lui. Stack-ul se decide într-o singură ședință: o aplicație web, o bază Postgres, ceva stocare de obiecte, mail. Apoi cineva întreabă dacă baza de date ar trebui găzduită sau self-hosted, și camera se împarte după obiceiuri. Răspunsul util nu e o preferință. E rezultatul a șase întrebări despre responsabilități, și de multe ori e diferit pentru aplicație, pentru bază și pentru fișiere.

Pornește de la responsabilități, nu de la preferințe

Hosted înseamnă că un furnizor rulează mașinile. Nu înseamnă că furnizorul rulează proiectul. La AWS împărțirea e formulată ca securitatea cloud-ului versus securitatea din cloud: AWS protejează infrastructura, iar clientul patch-uiește sistemul de operare invitat și aplicațiile, configurează firewall-ul, administrează datele, decide cine are acces și configurează baza de date. Este cea mai clară descriere publică a liniei. Vezi modelul de responsabilitate partajată AWS.

Legislația privind datele trasează o a doua linie care nu se mișcă odată cu alegerea găzduirii. Când un furnizor stochează date personale în numele clientului, el este persoană împuternicită, clientul este operator, iar operatorul rămâne răspunzător. Comitetul European pentru Protecția Datelor folosește exact acest exemplu în ghidul despre operator și împuternicit: un angajator al cărui furnizor de găzduire prelucrează datele angajaților trebuie să dea instrucțiuni și să încheie un contract conform articolului 28, iar operatorul „rămâne responsabil pentru implementarea măsurilor tehnice și organizatorice adecvate”. Hosted sau self-hosted schimbă cine poate duce o obligație. Nu schimbă cine răspunde pentru ea.

Partea contractuală, adică acordul de prelucrare, subcontractanții și întrebarea locației, este tratată în unde stau datele clientului tău. Diferența operațională dintre o bază personală și una de producție este în self-hosting pentru baze de date: personal versus producție. Articolul de față este decizia dintre ele. Este o explicație, nu consultanță juridică.

Cele șase întrebări

1. Unde au voie să stea datele și ce spune contractul clientului?

Notează ce va stoca sistemul, apoi verifică ce a promis deja clientul altcuiva. Un client care vinde către instituții publice, bănci sau sistemul medical poate avea o clauză despre locul unde pot fi prelucrate datele clienților lui, iar clauza a fost semnată înainte să existe proiectul tău.

Alegerea regiunii este primul control concret. Fiecare proiect Supabase este implementat într-o singură regiune principală, care stabilește unde stau datele primare; documentația avertizează și că „alegerea regiunii este un control al locației datelor, nu o dovadă de conformitate”, pentru că o regiune generală Europa poate plasa proiectul la Londra sau Zürich, care nu sunt state membre UE (regiunile Supabase). Citește textul mic pentru regiunea concretă, nu pentru continent.

Și backup-urile sunt copii. Un dump nocturn replicat în altă țară rămâne date personale în acea țară, iar un inginer de suport cu acces la consolă rămâne o persoană care le poate citi. Dacă răspunsul clientului este „trebuie să rămână pe hardware-ul nostru”, lista scurtă de variante găzduite se golește și întrebarea e închisă.

2. Cine trebuie să poată face restore și în cât timp?

Cere două cifre în cuvintele clientului: câte date se pot pierde dacă sistemul cade și cât timp poate sta jos. Aceste două răspunsuri decid proiectarea backup-ului mai mult decât modelul de găzduire și sunt întrebările la care clienții răspund cel mai sincer, pentru că își imaginează luni dimineața.

Apoi verifică dacă backup-urile furnizorului acoperă cifrele. La Supabase, backup-urile automate zilnice există pe planurile Pro, Team și Enterprise, cu retenție de 7, 14 și 30 de zile; point-in-time recovery este un add-on plătit care arhivează write-ahead log-urile, promite un obiectiv de punct de recuperare de două minute în cel mai rău caz și înlocuiește backup-urile zilnice când e activat; un restore scoate proiectul offline (backup-uri Supabase). Aceeași pagină notează că backup-urile bazei nu includ obiectele din Storage API, deci restaurarea fișierelor este o procedură separată.

Dacă clientul spune „facem restore noi”, găzduirea e acceptabilă doar când poate obține o copie pe care o poate încărca. Documentația spune că backup-urile fizice nu sunt disponibile pentru descărcare directă, deci asta înseamnă un dump logic prin CLI sau pg_dump. Testează drumul înainte de semnarea contractului, nu în timpul incidentului.

3. Cine patch-uiește și cine decide când?

Un serviciu administrat scoate administratorul de sistem, nu decizia. Supabase rulează upgrade-uri Postgres când le pornești din dashboard; proiectul este scos offline, iar un upgrade eșuat readuce baza originală online (upgrade-uri Supabase). Cineva tot trebuie să observe că există o versiune minoră nouă, să citească notele, să aleagă o fereastră și să apese butonul.

Self-hosted, cineva ești tu, iar fereastra e a ta. Modul de eșec nu e o pană spectaculoasă. E o versiune pe care nimeni nu a mai actualizat-o de doi ani, o extensie care nu se mai compilează și un upgrade care acum cere un weekend în loc de douăzeci de minute. Numește persoana care citește notele de versiune. Dacă numele lipsește din predare, patch-ul nu se va întâmpla.

4. Ce buget și ce competențe rămân după predare?

Hosted transformă operațiunile într-o linie lunară care crește cu compute-ul, storage-ul, retenția backup-urilor și add-on-uri ca point-in-time recovery. Self-hosted le transformă în ore, plus o mașină, plus persoana care răspunde la telefon. Niciuna nu e mai ieftină în abstract.

Întrebarea care contează este ce există după terminarea proiectului. Un client cu echipă de operațiuni, platformă de containere și tură de on-call poate prelua o bază self-hosted și adesea o preferă, pentru că datele nu îi pleacă din rețea. O firmă de cinci oameni fără personal tehnic nu poate. Dacă facem self-hosting pentru ea, devenim singurii care pot repara ceva, ceea ce e un punct unic de eșec deghizat în control.

5. Ce se întâmplă când furnizorul își schimbă termenii?

Furnizorii schimbă termeni, prețuri și planuri. Termenii Supabase spun că poate „modifica acest acord (cu excepția comenzilor) din când în când, la discreția sa”, cu o notificare rezonabilă, iar utilizarea în continuare după data intrării în vigoare înseamnă acceptare (termenii Supabase). Este limbaj contractual normal și este totodată un risc pe care îl accepți în numele clientului.

Pune clientului o întrebare directă: dacă furnizorul acesta dublează prețul anul viitor, ce facem? Dacă răspunsul sincer este „plătim”, aceea este o decizie și trebuie scrisă. Măsurile de atenuare sunt plictisitoare și eficiente: ține evidența principală în tabele Postgres obișnuite, nu construi produsul în jurul unei funcții exclusive furnizorului și știi dinainte cât ar costa o săptămână de migrare.

6. Cum pleacă clientul dacă relația se termină?

Există două ieșiri, de la furnizor și de la noi, și ambele au nevoie de un drum testat. Pentru o bază Postgres formatul portabil este dump-ul logic: pg_dump scrie un script sau o arhivă care se poate încărca pe alte mașini și alte arhitecturi (PostgreSQL pg_dump). Aceeași documentație spune răspicat că utilitarul „nu este, în general, alegerea potrivită pentru backup-uri regulate ale bazelor de producție”, așa că folosește-l pentru ieșiri și backup-uri fizice sau write-ahead log-uri pentru recuperare.

Un dump al bazei nu este proiectul. Utilizatorii și hash-urile de parole, obiectele din storage, sarcinile programate, înregistrările DNS și credențialele de mail stau altundeva. Inventariază fiecare, stabilește cine ține originalul și exersează exportul o dată, cât timp toată lumea e calmă.

Unde duc răspunsurile

Hosted se potrivește când clientul nu are capacitate de operațiuni, cerințele sunt obișnuite, datele pot sta într-o regiune numită, clientul acceptă furnizorul ca împuternicit, iar costul lunar e bugetat, nu sperat. Este un caz real, nu un compromis. Se potrivește și când alternativa este un server în birou pe care nimeni nu face backup.

Self-hosted se potrivește când un contract sau un regulator cere ca datele să rămână în infrastructura clientului, când clientul rulează deja servere și are oameni de gardă, când volumul de muncă are nevoie de o extensie, o versiune sau o configurație pe care planul administrat nu o oferă, sau când o încărcare mare și constantă face o mașină fixă mai ieftină decât o factură pe utilizare.

Majoritatea proiectelor pe care le vedem sunt mixte, și e în regulă. Aplicația rulează pe o platformă administrată, baza stă pe mașina virtuală a clientului, fișierele intră în storage-ul clientului, mail-ul trece printr-un furnizor. Răspunde la cele șase întrebări pentru fiecare componentă, nu o dată pentru tot stack-ul.

Răspunsul care ar trebui să te îngrijoreze nu este „hosted” sau „self-hosted”. Este „hosted pentru că ne e mai ușor nouă” sau „self-hosted pentru că e mai sigur”, fără un operator numit și fără un restore testat în spate.

Obligații de predare, în ambele cazuri

• Credențiale. Domeniul și registrarul, DNS-ul, contul furnizorului cu facturarea pe numele clientului, superuserul bazei, cheile de criptare, credențialele de mail, tokenurile API. Predă-le printr-un password manager, notează ce om le ține pe fiecare și revocă accesurile noastre acolo unde contractul spune că am terminat.
• Documentație. O diagramă de arhitectură, variabilele de mediu și un runbook cu trei proceduri: deploy, restore și escaladare. Scris pentru persoana care vine după noi.
• Dovada backup-ului. Data ultimului test de restore, cine l-a rulat, cât a durat și ce lipsea. Un job de backup verde dovedește că un job a rulat. Nu dovedește că datele pot reveni.
• Un operator numit. O persoană cu nume, telefon și atribuții scrise, fie în client, fie sub un contract de suport cu ore atașate. „Echipa” nu este nimeni la trei dimineața.

Aceleași patru lucruri se aplică ambelor modele; diferă doar cine le face.

Ce costă o greșeală, în mecanisme

O lipsă la restore costă scrierile dintre ultimul backup utilizabil și incident. Cu backup-uri doar zilnice, asta înseamnă până la o zi de muncă, iar pierderea nu sunt datele, ci încrederea oamenilor care le-au introdus.

Un sistem nepatch-uit costă fereastra dintre divulgare și exploatare, care e scurtă. Dacă o breșă atinge date personale, operatorul are 72 de ore de la momentul în care ia cunoștință ca să notifice autoritatea de supraveghere, iar împuternicitul trebuie să informeze operatorul fără întârziere nejustificată; EDPB descrie ambele obligații în ghidul privind notificarea breșelor. Un client care află de breșă de la un client al lui a pierdut deja acea fereastră.

Lock-in-ul costă o migrare, iar o migrare se plătește în schemă, autentificare, storage, DNS și retestare, nu într-un download. Greșeala de regiune costă aceeași migrare, în cel mai prost moment. Un operator nenominalizat costă orele pierdute ca să afli cine are credențialele, de obicei mai multe decât reparația.

Clienții din România lucrează și sub Legea 190/2018, care pune în aplicare la nivel național prevederi specifice din GDPR, iar breșele se notifică la ANSPDCP. Nimic din toate astea nu se schimbă cu modelul de găzduire. Se schimbă ce trebuie să poată arăta clientul.

Cum lucrăm noi la Danube Labs

Scriem cele șase răspunsuri în primul document al proiectului, înainte să alegem infrastructura, iar același document devine lista de predare. Când clientul nu are operator, spunem asta în document și punem suportul în preț, în loc să îl lăsăm implicit.

Dacă pornești un proiect și vrei o a doua părere despre împărțire, vezi proiectele noastre de dezvoltare web sau programează un apel introductiv gratuit.