Alternatywa tylko UE dla Fly.io.
Fly.io ("Fly") to platforma edge compute z siedzibą w USA, uruchamiająca microVMs Firecracker w ponad 30 regionach, w tym w Amsterdamie, Frankfurcie, Paryżu, Madrycie i Sztokholmie. Fly Inc. to spółka prawa stanu Delaware, regiony UE są zlokalizowane w UE, ale kontrolowane z USA, a CLOUD Act ma zastosowanie. Podejście techniczne Fly (microVMs na brzegu sieci, niemal natychmiastowy cold start, prosty `fly deploy`) jest rzeczywiście innowacyjne; zastąpienie go suwerennym stosem europejskim oznacza zamianę tego konkretnego, wieloregionowego modelu edge na wdrożenie ograniczone do jednego regionu lub samodzielnie zarządzany odpowiednik na infrastrukturze europejskiej.
- Dostawca
- Fly.io
- Siedziba
- Chicago, IL
- 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 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 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ą Fly.io
Migracje z Fly.io, które przeanalizowaliśmy, dotyczą regulowanych obciążeń (SaaS w ochronie zdrowia, fintech), gdzie wieloregionowy model edge był miłym dodatkiem, ale amerykański, jurysdykcyjnie zależny procesor stanowił blokadę. Uczciwa odpowiedź dla tych obciążeń: większość z nich tak naprawdę nie potrzebuje 30 regionów, tylko 2-3 regionów UE z niskim opóźnieniem. To wymaganie spełniają dwa z naszych regionów UE wraz z CDN takim jak Bunny.net dla zasobów statycznych - co razem obsługuje użytkowników z UE z opóźnieniem poniżej 50 ms i pełną jurysdykcją UE.
Fly.io 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 Fly.io na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.
Fly Machines (microVMs)
- 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
- Dla większości obciążeń, zwykłe maszyny wirtualne z wdrożeniem multi-region przez DNS GeoIP pokrywają dany przypadek użycia. Dla prawdziwego modelu microVM-per-request, self-hosted Firecracker na obliczeniach w UE jest suwerenną odpowiedzią.
Fly Apps (PaaS layer)
- 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
- Funkcja multi-server w Coolify obsługuje wzorce wdrożeń multi-region.
Fly Postgres (clustered)
- 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
- Patroni na unijnym compute to open-source'owy wzorzec, na którym oparta jest własna oferta Postgres od Fly.
Fly Redis (Upstash)
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. Redis lub Valkey, z Sentinel do failover.
- Notatka inżynierska
- Uwaga: sam Upstash ma siedzibę w USA, więc Fly Redis to konfiguracja US-on-US.
Fly Volumes
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. Ceph RBD lub Longhorn dla wolumenów natywnych dla Kubernetes.
- Notatka inżynierska
- Standardowe woluminy oparte na NVMe; równoważne rozmiarem.
Fly Proxy (Anycast)
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. HAProxy lub Nginx, z keepalived do failover.
- Notatka inżynierska
- Health checks, connection draining i sticky sessions - wszystko zostaje zachowane. TLS terminowany jest tutaj, z automatycznym odnawianiem certyfikatów.
Fly Postgres failover (multi-region)
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. Failover PostgreSQL zarządzany przez Patroni pomiędzy węzłami, z automatyczną promocją.
- Notatka inżynierska
- Dla wdrożeń multi-region tylko w UE (np. NL + DE w trybie active-active z regionalnym failoverem), Patroni sobie z tym poradzi.
Fly Secrets
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. HashiCorp Vault lub Infisical, self-hosted, z automatyczną rotacją lease.
- Notatka inżynierska
- Vault to rozwiązanie produkcyjnej klasy dla każdego nietrywialnego obciążenia związanego z zarządzaniem sekretami.
flyctl / fly deploy DX
- Czego używamy zamiast tego
- Binadit DevOps & Support. kubectl, Terraform i GitLab CI, z wrapperami dostosowanymi do projektu tam, gdzie to pomaga.
- Notatka inżynierska
- Różnica w DX jest realna, ale możliwa do zniwelowania. `coolify deploy` z Coolify jest najbliższym odpowiednikiem.
Fly LiteFS (replicated SQLite)
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. PostgreSQL z read replicas, lub Litestream tam, gdzie model SQLite naprawdę się sprawdza.
- Notatka inżynierska
- Replikowane SQLite to eleganckie rozwiązanie dla aplikacji z jednym zapisującym i przewagą odczytów. Tam, gdzie ścieżka zapisu jest rywalizowana, bezpieczniejszym wyborem jest PostgreSQL.
Jak migrujemy z Fly.io
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
Decyzja o strategii regionalnej
Sprawdź, których regionów Fly faktycznie używasz i które obsługują realny ruch. Dla większości aplikacji skierowanych do klientów z UE wystarczą 2-3 regiony UE; dla aplikacji globalnych zdecyduj o wzorcu multi-region (DNS GeoIP, Anycast, failover regionalny).
-
Dni 4-10
Baza danych + migracja storage
Fly Postgres zreplikowany do zarządzanego PostgreSQL w UE lub klastra Patroni. Woluminy lustrzane. Sekrety przeniesione do Vault.
-
Tygodnie 2-4
Migracja aplikacji
Aplikacje ponownie wdrożone na Kubernetes w Binadit. DNS przeniesiony na routing GeoIP, jeśli wymagana jest obsługa wielu regionów. Konto Fly wyłączone po oknie weryfikacyjnym.
5-letnie TCO przy migracjach z Fly różni się bardziej niż w przypadku innych migracji z chmur amerykańskich, ponieważ model cenowy Fly jest nietypowy (rozliczanie microVM co sekundę). Dla obciążeń o stałym charakterze infrastruktura UE jest dramatycznie tańsza. Dla bardzo nierównomiernych obciążeń z długimi okresami bezczynności, skalowanie do zera oferowane przez Fly jest trudne do dorównania kosztowo w suwerennej przestrzeni UE bez platformy kontenerowej ze skalowaniem do zera.
Często zadawane pytania
Marketing Fly "no surveillance" - czy rzeczywiście oznacza suwerenność?
Jak zastępujemy funkcję "microVM cold start"?
A co z LiteFS dla SQLite na brzegu sieci (edge)?
Ile trwa wyjście z Fly.io?
Czy istnieją prawdziwie podobne do Fly opcje w UE?
A co z ofertą GPU od Fly?
Zaplanuj wyjście z Fly.io.
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.