Alternatywa tylko UE dla Akamai Linode.
Linode został przejęty przez Akamai w 2022 roku i przemianowany na Akamai Connected Cloud. Produkt to nadal ta sama lubiana, przyjazna deweloperom chmura, ale spółka macierzysta się zmieniła: Akamai Technologies Inc. to amerykańska korporacja z siedzibą w Massachusetts, a CLOUD Act dotyczy wszystkich danych przechowywanych przez podmioty Akamai na całym świecie. Centra danych we Frankfurcie i Londynie znajdują się w UE, ale są kontrolowane przez USA. Dla zespołów z UE, które pierwotnie wybrały Linode ze względu na prostotę i cenę, zarządzany stos UE oferuje tę samą prostotę przy pełnej jurysdykcji UE i zazwyczaj niższych rachunkach.
- Dostawca
- Akamai Linode
- Siedziba
- Cambridge, MA (Akamai)
- 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ą Akamai Linode
Migracje z Linode/Akamai, które obserwujemy, wynikają z dwóch powodów: klienci B2B SaaS, których klienci enterprise (zwłaszcza europejskie banki i sektor publiczny) oznaczyli Akamai jako procesora narażonego na CLOUD Act, lub startup prowadzony przez deweloperów, który wyrósł na Linode i teraz potrzebuje zgodności ze Schrems II dla kontraktu enterprise. Migracja z Linode jest technicznie prosta - API i oferta produktowa Linode są minimalne - a alternatywy z UE zamknęły wszelkie luki funkcjonalne, które istniały historycznie.
Akamai Linode 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 Akamai Linode na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.
Linode Compute Instances
- 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.
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.
Managed Databases
- 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
- Dla PostgreSQL i MySQL, alternatywy z UE oferują pełną paretę funkcji. Dla MongoDB, Atlas EU istnieje, ale ma amerykańską spółkę-matkę - self-hosted na infrastrukturze UE jest suwerenną odpowiedzią.
LKE (Linode Kubernetes Engine)
- 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
- Helm charts przenoszą się bez problemów. Konfiguracja ingress controllera z LKE przenosi się na standardowy nginx-ingress bez zmian.
NodeBalancers
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. HAProxy lub Nginx, z keepalived do failover.
- Notatka inżynierska
- Standardowy load balancing L4/L7 we wszystkich opcjach w UE.
Block Storage
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. Ceph RBD lub Longhorn dla wolumenów natywnych dla Kubernetes.
- Notatka inżynierska
- Migawka wolumenu + przywrócenie to standardowy wzorzec migracji; w przypadku działających produkcyjnie obciążeń stosujemy migrację opartą na rsync z oknami awaryjnymi w trybie tylko do odczytu.
DNS Manager
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.
- Notatka inżynierska
- Eksport strefy z Linode i import do nowego dostawcy.
Cloud Firewall
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. Coraza lub ModSecurity z OWASP Core Rule Set, plus CrowdSec do blokowania behawioralnego.
- Notatka inżynierska
- Wszyscy dostawcy z UE oferują reguły firewalla typu cloud-native.
Linode Backups
- Czego używamy zamiast tego
- Binadit Managed Cloud Platform. restic i pgBackRest dla danych, Velero dla stanu Kubernetes, do izolowanego storage w UE.
- Notatka inżynierska
- Dla obciążeń produkcyjnych standardowym suwerennym wzorcem jest Borg/restic z zewnętrznym repozytorium hostowanym w UE.
Akamai CDN integration
- 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
- Historyczna przewaga Akamai w zakresie CDN nie stanowi już fosy w przestrzeni suwerennych rozwiązań UE.
Linode VLAN
- Czego używamy zamiast tego
- Binadit Private Infrastructure. Izolowane VLAN-y z WireGuard do site-to-site i dostępu operatorów.
- Notatka inżynierska
- Prywatne sieci między maszynami wirtualnymi (cross-VM) dostępne we wszystkich opcjach UE.
Jak migrujemy z Akamai Linode
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-2
Inwentaryzacja
Zestawienie instancji, wolumenów, NodeBalancers, klastrów LKE, stref DNS. Mapowanie wszelkich automatyzacji Linode CLI/API wymagających przepisania.
-
Dni 3-7
Miękka podmiana
DNS, Object Storage i backup vault przenoszone jako pierwsze. Repliki bazy danych wstępnie skonfigurowane na zarządzanej bazie danych w UE. CI/CD zaktualizowane do wdrażania równolegle u obu dostawców.
-
Tygodnie 2-4
Przełączenie Compute
Instancje ponownie uruchomione na infrastrukturze obliczeniowej Binadit. Workloady LKE przeniesione na Kubernetes na Binadit. Przełączenie bazy danych przez replikację logiczną. NodeBalancer zastąpiony. Wycofanie Linode po tygodniowym okresie weryfikacji.
5-letnie TCO na migracjach z Linode: zazwyczaj 30-50% taniej, przy czym oszczędności koncentrują się na compute i przepustowości. Historycznie „1TB transferu w cenie na Linode” była przewagą cenową. Compute w UE obecnie zazwyczaj obejmuje znacznie więcej transferu na serwer, co jest lepszą ofertą dla typowych obciążeń.
Często zadawane pytania
Akamai jest teraz właścicielem Linode - czy to zmienia analizę RODO?
Czy stracimy prostotę operacyjną, dla której wybraliśmy Linode?
A co konkretnie z zarządzanym Kubernetes?
Ile trwa wyjście z Linode?
Czy możemy zachować nasz CDN, jeśli przeniesiemy compute do was?
Czy zespół wsparcia Linode w UE cokolwiek zmienia?
Zaplanuj wyjście z Akamai Linode.
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.