Alternatywa tylko UE dla DigitalOcean.

DigitalOcean to amerykański cloud zorientowany na developerów - konkurencyjne ceny, przejrzysty UX i region w Amsterdamie, który usypia czujność wielu zespołów z UE, sugerując, że kwestia rezydencji danych jest rozwiązana. Nie jest: DigitalOcean LLC to firma zarejestrowana w stanie Delaware, jej centrum danych w Amsterdamie działa pod amerykańską kontrolą korporacyjną, a CLOUD Act ma zastosowanie. Dobra wiadomość jest taka, że migracja z DigitalOcean na infrastrukturę objętą jurysdykcją UE, którą dla Ciebie przeprowadzamy, jest jedną z najczystszych opisanych w tym przewodniku - powierzchnia API DigitalOcean jest niewielka, a większość workloadów przeniesionych poza nią raportuje niższe rachunki oraz taką samą lub lepszą wydajność.

Stany Zjednoczone Stack zastępczy, wyłącznie UE 12 zmapowanych usług

Umów rozmowę Najpierw zeskanuj swoją domenę

Dostawca: DigitalOcean
Siedziba: New York, NY
Jurysdykcja: Stany Zjednoczone
Reżim prawny: CLOUD Act, FISA 702

"Region UE" to nie suwerenność. Decydują cztery pytania.

Rezydencja danych mówi, gdzie leżą bity. Suwerenność mówi, który system prawny może wymusić dostęp. Odpowiedź musi się bronić we wszystkich czterech punktach, inaczej stack nie jest suwerenny.

Rezydencja

Gdzie dane są fizycznie przechowywane?

Nie "w chmurze": które centrum danych, w jakim kraju, pod jaką jurysdykcją.

Podprzetwarzający

Kto jeszcze znajduje się w Państwa ścieżce danych?

Każdy dostawca dotykający danych: CDN, przekaźnik e-mail, tracker błędów, pipeline analityczny.

Jurysdykcja

Czyje prawa mogą wymusić ujawnienie?

Dostawca z siedzibą w USA podlega FISA 702 i CLOUD Act, nawet gdy dane leżą we Frankfurcie.

Depozyt kluczy

Kto faktycznie ma klucze szyfrujące?

Jeśli dostawca chmury trzyma zarówno dane, jak i klucze, może je odczytać, niezależnie od jakiejkolwiek umowy powierzenia.

Nie spełnia AWS · Azure · GCP · Region UE

Nie spełnia kryterium jurysdykcji i depozytu kluczy.

Bity w UE, spółka matka w USA, podprzetwarzający z USA w domyślnej ścieżce, klucze zarządzane przez dostawcę.

Spełnia Stack zarządzany przez Binadit

Spełnia wszystkie cztery kryteria.

Hostowane w UE na infrastrukturze z siedzibą europejską. Zero podprzetwarzających z USA w domyślnej ścieżce. Klucze klienta lub europejskiego KMS. Wymienieni z nazwy w Państwa DPA z Artykułu 28.

Dlaczego zespoły wychodzą DigitalOcean

Migracje z DigitalOcean, które przeprowadzaliśmy, niemal zawsze wynikały z jednego powodu: audytu klienta (B2B SaaS) lub przeglądu zgodności, w którym uznano, że „DigitalOcean Amsterdam” jest niewystarczający w świetle Schrems II, a klient musiał albo dodać kosztowne środki uzupełniające (szyfrowanie BYOK, które niweczy wartość usługi zarządzanej), albo dokonać migracji. Migracja jest zwykle tańszą opcją. Praca techniczna jest niewielka, ponieważ oferta produktowa DigitalOcean jest celowo minimalna, co upraszcza mapowanie na rozwiązania unijne.

DigitalOcean usługi i ich odpowiedniki tylko z UE

Migracja to nie "zamiana jednej skrzynki na drugą". Poniższe mapowanie jest tym, co uruchamiamy dla klientów opuszczających DigitalOcean na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.

DigitalOcean usługa	Czego używamy zamiast tego	Notatka inżynierska
Droplets	Binadit Managed Cloud Platform. Maszyny wirtualne KVM na Debianie lub Ubuntu, provisionowane za pomocą Terraform i konfigurowane za pomocą Ansible.	Dobieramy rozmiar instancji na podstawie rzeczywistego profilu obciążenia, a nie sztywnych poziomów z cennika, dzięki czemu większość migracji kończy się mniejszą liczbą lepiej wykorzystanych maszyn.
Spaces (object storage)	Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.	Kompatybilność z S3 we wszystkich opcjach; migracja to jedna zmiana endpointu w konfiguracji SDK.
Managed Databases (PostgreSQL, MySQL, Redis)	Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.	Replikacja strumieniowa pozwala na przełączenie z przestojem liczonym w sekundach zamiast okna serwisowego, a przywracanie danych jest regularnie testowane, a nie zakładane.
App Platform (PaaS)	Binadit Managed Cloud Platform. Obrazy Docker budowane w GitLab CI i wdrażane na Kubernetes, ze środowiskami review dla każdego brancha.	App Platform nie ma bezpośredniego suwerennego odpowiednika na poziomie PaaS. Coolify (open-source, self-hosted) zapewnia doświadczenie użytkownika podobne do Heroku na infrastrukturze UE.
Kubernetes (DOKS)	Binadit Managed Cloud Platform. Kubernetes na Debianie lub Talos, z siecią Cilium i cert-manager do certyfikatów.	Twoje manifesty i Helm charts przenoszone są bez zmian. Zmienia się ingress class i storage class, a my zajmujemy się obydwoma.
Load Balancers	Binadit Managed Cloud Platform. HAProxy lub Nginx, z keepalived do failover.	Dla większości przypadków użycia zarządzany LB u dostawców z UE jest wystarczający; dla zaawansowanych reguł, standardowym wzorcem jest HAProxy na małej maszynie wirtualnej.
Volumes (block storage)	Binadit Managed Cloud Platform. Ceph RBD lub Longhorn dla wolumenów natywnych dla Kubernetes.	Standardowy block storage oparty na NVMe we wszystkich opcjach w UE; wydajność jest porównywalna lub lepsza.
DNS (DigitalOcean DNS)	Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.	Migracja polega na eksporcie i ponownym imporcie strefy; to kwestia kilku minut pracy.
Floating IPs	Binadit Managed Cloud Platform. Alokacja statycznych IP z keepalived do failover między węzłami.	Wszyscy dostawcy oferują odpowiednik wzorca failover-IP.
CDN (DigitalOcean CDN)	Wdrażamy i utrzymujemy dla Ciebie CDN w UE: Bunny.net lub KeyCDN, z cache'owaniem Nginx i Varnish na Twoim origin.	CDN to jedna z niewielu warstw, których nie utrzymujemy samodzielnie. Wybieramy dostawcę z UE, konfigurujemy nagłówki cache, strategię czyszczenia cache oraz origin shielding, i zarządzamy tym w ramach usługi managed.
Monitoring (DO Monitoring)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki i Tempo, połączone za pomocą OpenTelemetry.	OpenTelemetry zapewnia przenośną instrumentację, a brak cennika naliczanego per metrykę czy per trace oznacza, że zespoły przestają ograniczać próbkowanie potrzebnych im danych.
Container Registry	Binadit DevOps & Support. Harbor lub rejestr kontenerów GitLab, ze skanowaniem podatności przy każdym push.	Harbor to rejestr open-source klasy produkcyjnej; obsługujemy go dla klientów.

Droplets

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Maszyny wirtualne KVM na Debianie lub Ubuntu, provisionowane za pomocą Terraform i konfigurowane za pomocą Ansible.
Notatka inżynierska: Dobieramy rozmiar instancji na podstawie rzeczywistego profilu obciążenia, a nie sztywnych poziomów z cennika, dzięki czemu większość migracji kończy się mniejszą liczbą lepiej wykorzystanych maszyn.

Spaces (object storage)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.
Notatka inżynierska: Kompatybilność z S3 we wszystkich opcjach; migracja to jedna zmiana endpointu w konfiguracji SDK.

Managed Databases (PostgreSQL, MySQL, Redis)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. PostgreSQL lub MySQL z Patroni do failover i pgBackRest do point-in-time recovery.
Notatka inżynierska: Replikacja strumieniowa pozwala na przełączenie z przestojem liczonym w sekundach zamiast okna serwisowego, a przywracanie danych jest regularnie testowane, a nie zakładane.

App Platform (PaaS)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Obrazy Docker budowane w GitLab CI i wdrażane na Kubernetes, ze środowiskami review dla każdego brancha.
Notatka inżynierska: App Platform nie ma bezpośredniego suwerennego odpowiednika na poziomie PaaS. Coolify (open-source, self-hosted) zapewnia doświadczenie użytkownika podobne do Heroku na infrastrukturze UE.

Kubernetes (DOKS)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Kubernetes na Debianie lub Talos, z siecią Cilium i cert-manager do certyfikatów.
Notatka inżynierska: Twoje manifesty i Helm charts przenoszone są bez zmian. Zmienia się ingress class i storage class, a my zajmujemy się obydwoma.

Load Balancers

Czego używamy zamiast tego: Binadit Managed Cloud Platform. HAProxy lub Nginx, z keepalived do failover.
Notatka inżynierska: Dla większości przypadków użycia zarządzany LB u dostawców z UE jest wystarczający; dla zaawansowanych reguł, standardowym wzorcem jest HAProxy na małej maszynie wirtualnej.

Volumes (block storage)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Ceph RBD lub Longhorn dla wolumenów natywnych dla Kubernetes.
Notatka inżynierska: Standardowy block storage oparty na NVMe we wszystkich opcjach w UE; wydajność jest porównywalna lub lepsza.

DNS (DigitalOcean DNS)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.
Notatka inżynierska: Migracja polega na eksporcie i ponownym imporcie strefy; to kwestia kilku minut pracy.

Floating IPs

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Alokacja statycznych IP z keepalived do failover między węzłami.
Notatka inżynierska: Wszyscy dostawcy oferują odpowiednik wzorca failover-IP.

CDN (DigitalOcean CDN)

Czego używamy zamiast tego: Wdrażamy i utrzymujemy dla Ciebie CDN w UE: Bunny.net lub KeyCDN, z cache'owaniem Nginx i Varnish na Twoim origin.
Notatka inżynierska: CDN to jedna z niewielu warstw, których nie utrzymujemy samodzielnie. Wybieramy dostawcę z UE, konfigurujemy nagłówki cache, strategię czyszczenia cache oraz origin shielding, i zarządzamy tym w ramach usługi managed.

Monitoring (DO Monitoring)

Czego używamy zamiast tego: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki i Tempo, połączone za pomocą OpenTelemetry.
Notatka inżynierska: OpenTelemetry zapewnia przenośną instrumentację, a brak cennika naliczanego per metrykę czy per trace oznacza, że zespoły przestają ograniczać próbkowanie potrzebnych im danych.

Container Registry

Czego używamy zamiast tego: Binadit DevOps & Support. Harbor lub rejestr kontenerów GitLab, ze skanowaniem podatności przy każdym push.
Notatka inżynierska: Harbor to rejestr open-source klasy produkcyjnej; obsługujemy go dla klientów.

Jak migrujemy z DigitalOcean

Typowa migracja segmentu mid-market przebiega w trzech fazach. Poniższe liczby zakładają zespół inżynierski 6-10 osób i umiarkowanie złożony stack aplikacyjny.

Dni 1-3

Inwentaryzacja i zależności

Zestawienie każdego Droplet, Database, Space i wdrożenia App Platform. Identyfikacja wszelkich API specyficznych dla DigitalOcean lub automatyzacji doctl wymagających przepisania. Wynik: przejrzysty plan migracji bez niespodzianek.
Dni 4-10

Najpierw miękkie zależności

DNS, Spaces i CDN przenoszone jako pierwsze. Repliki bazy danych wstępnie skonfigurowane w zarządzanej usłudze w UE. Rejestr kontenerów przeniesiony na Harbor. Monitoring na EU Prometheus.
Tygodnie 2-5

Przełączenie Compute i DB

Droplets ponownie uruchomione na compute Binadit z tymi samymi obrazami. Przełączenie bazy danych z replikacją logiczną. Workloady App Platform przeniesione na Kubernetes w Binadit. Przełączenie Load Balancera z przesunięciem DNS.

5-letnie TCO przy migracji z DigitalOcean: zazwyczaj 40-60% taniej, przy czym największe oszczędności dotyczą compute, gdzie równoważne specyfikacje są zazwyczaj o połowę tańsze, oraz zarządzanych baz danych. Przewagą DigitalOcean jest UX App Platform, który suwerenny stos UE zastępuje przez Coolify lub samodzielnie zarządzany PaaS.

Często zadawane pytania

Zobacz wszystkie często zadawane pytania

DigitalOcean ma centra danych w Amsterdamie i Frankfurcie - czy to spełnia wymogi RODO?

Rezydencja tak, suwerenność nie. Centrum danych w Amsterdamie jest własnością i jest zarządzane przez DigitalOcean LLC, podmiot kontrolowany przez USA. CLOUD Act pozwala władzom USA żądać ujawnienia danych w dowolnym miejscu na świecie. Dla obciążeń wrażliwych na Schrems II, to narażenie nie jest rozwiązane przez lokalizację centrum danych.

Czy niezawodność ucierpi, jeśli odejdziemy od DigitalOcean?

Nie w naszym doświadczeniu, ale szczera odpowiedź jest taka, że niezawodność wynika bardziej z architektury niż z logo. Pojedyncza instancja bez failover jest krucha wszędzie. My zamiast tego budujemy redundancję na warstwach, które mają znaczenie: replikowane bazy danych z przetestowanym failover, load balancing między nodami oraz monitoring, który informuje nas, zanim poinformuje Twoich klientów. To właśnie ta część zmiany wpływa na Twój uptime, a nie wybór datacenter.

A co konkretnie z zamiennikiem App Platform?

App Platform jest naprawdę przydatny dla małych zespołów, które nie chcą zarządzać infrastrukturą. Coolify, self-hosted i open source, zapewnia porównywalne doświadczenie App Platform na obliczeniach w UE. Dla zespołów, które chcą, aby było to zarządzane, prowadzimy platformę kontenerową za Was.

Czy możemy migrować stopniowo, czy musi się to odbyć jednorazowo?

Migracja stopniowa jest normą. Uruchom oba dostawców równolegle poprzez podział ruchu na poziomie DNS, migruj obciążenie po obciążeniu, wyłącz DigitalOcean po przeniesieniu ostatniej usługi. Typowy czas realizacji: 4-8 tygodni dla obciążeń mid-market, 2-4 tygodnie dla mniejszych.

Ile trwa wyjście z DigitalOcean?

Dla typowego obciążenia (5-20 Droplets, 1-2 zarządzane bazy danych, Spaces, DNS): 3-6 tygodni. Z partnerem prowadzącym zarządzaną infrastrukturę: 2-4 tygodnie. Praca techniczna jest lekka; harmonogram wyznaczają bramki walidacyjne i dostępność zespołu.

Czy migracja spowoduje przestój?

Nie, jeśli zrobione jest to właściwie. Migracja bazy danych wykorzystuje replikację logiczną, więc przełączenie sprowadza się do jednej zmiany DNS lub connection-string. Migracja compute wykorzystuje blue-green na poziomie load balancera lub DNS. Object storage wykorzystuje podwójny zapis (dual-write) w oknie migracyjnym. Zero-downtime to standardowe oczekiwanie.

Zaplanuj wyjście z DigitalOcean.

30-minutowa rozmowa zakresowa. Mapujemy Państwa stack względem alternatyw tylko z UE, szacujemy nakład pracy migracji i mówimy, czy to właściwa decyzja.

Umów rozmowę Porównaj innego dostawcę