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.

Stany Zjednoczone Stack zastępczy, wyłącznie UE 10 zmapowanych usług
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 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ą 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.

  1. 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).

  2. 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.

  3. 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.

Marketing Fly "no surveillance" - czy rzeczywiście oznacza suwerenność?
Fly.io było transparentne w kwestii nieznajdowania się na amerykańskich listach nadzoru nad infrastrukturą krytyczną hyperscalerów. To deklaracja operacyjna, a nie jurysdykcyjna. Jako amerykańska spółka z Delaware, Fly podlega CLOUD Act niezależnie od tego, jak się pozycjonuje. Ekspozycja prawna jest taka sama jak w przypadku każdego innego dostawcy podlegającego jurysdykcji USA.
Jak zastępujemy funkcję "microVM cold start"?
Dla większości obciążeń zimny start microVM jest miłym dodatkiem, a nie twardym wymogiem. Jeśli naprawdę go potrzebujesz, rozwiązaniem jest self-hosted Firecracker na infrastrukturze obliczeniowej w UE (ta sama technologia, której używa Fly). Wdrażamy to dla klientów z konkretnymi potrzebami w zakresie microVM.
A co z LiteFS dla SQLite na brzegu sieci (edge)?
LiteFS jest open-source. Self-hosting na infrastrukturze obliczeniowej w UE z replikacją wieloregionalną. Migracja jest w większości mechaniczna, ponieważ LiteFS wykorzystuje standardowe SQLite pod spodem.
Ile trwa wyjście z Fly.io?
Dla typowego obciążenia (kilka aplikacji, klaster Postgres, kilka wolumenów): 2-4 tygodnie. Dla konfiguracji multi-region z Anycast i LiteFS: 4-8 tygodni. Największym ryzykiem harmonogramowym jest odtworzenie wzorca multi-region, a nie sama praca techniczna.
Czy istnieją prawdziwie podobne do Fly opcje w UE?
Jeszcze nie ma dokładnego odpowiednika 1:1 w przestrzeni suwerennej UE. Najbliższą kombinacją jest Coolify multi-server + DNS GeoIP do routingu + zarządzany Postgres w UE. Nie jest to tak dopracowane jak zintegrowane doświadczenie Fly, ale jest suwerenne i operacyjnie prostsze kosztem nieco gorszego DX.
A co z ofertą GPU od Fly?
Instancje GPU Fly (A10, L40S) konkurują w obciążeniach inferencyjnych. Dedykowany europejski sprzęt GPU to suwerenna alternatywa dla obliczeń GPU obecnej generacji. W przypadku starszych generacji dedykowany europejski sprzęt GPU jest konkurencyjny cenowo.

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.