Alternativa apenas UE a Akamai Linode.
A Linode foi adquirida pela Akamai em 2022 e rebatizada como Akamai Connected Cloud. O produto é a mesma cloud bem-conceituada e amigável para developers, mas a empresa-mãe mudou: a Akamai Technologies Inc. é uma corporação americana sediada no Massachusetts, e o CLOUD Act aplica-se a todos os dados detidos por entidades Akamai a nível global. Os datacenters de Frankfurt e Londres estão localizados na UE mas são controlados pelos EUA. Para equipas da UE que originalmente escolheram a Linode pela sua simplicidade e preços, uma stack gerida na UE oferece a mesma simplicidade com jurisdição totalmente europeia e, tipicamente, faturas mais baixas.
- Fornecedor
- Akamai Linode
- Sede
- Cambridge, MA (Akamai)
- Jurisdição
- Estados Unidos
- Regime jurídico
- CLOUD Act, FISA 702
"Região UE" não é soberania. Quatro perguntas decidem.
A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.
- Residência
-
Onde os dados estão fisicamente armazenados?
Não "na cloud": que centro de dados, em que país, sob que jurisdição.
- Subprocessadores
-
Quem mais está no seu caminho de dados?
Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.
- Jurisdição
-
Quais leis podem forçar a divulgação?
Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.
- Custódia de chaves
-
Quem detém realmente as chaves de cifragem?
Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.
Falha em jurisdição e custódia de chaves.
Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.
Passa nos quatro.
Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.
Porque é que as equipas estão a sair Akamai Linode
As saídas da Linode/Akamai que vemos surgem de dois ângulos: uma SaaS B2B cujos clientes empresariais (especialmente bancos europeus e o setor público) sinalizaram a Akamai como um processador exposto ao CLOUD Act, ou uma startup liderada por developers que cresceu sobre a Linode e agora precisa de conformidade com o Schrems II para um contrato empresarial. A migração da Linode é mecanicamente simples - a API e o conjunto de produtos da Linode são minimalistas - e as alternativas na UE já eliminaram quaisquer lacunas de funcionalidades que existiam historicamente.
Akamai Linode serviços e os seus equivalentes apenas na UE
Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Akamai Linode com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.
Linode Compute Instances
- O que usamos no lugar
- Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
- Nota de engenharia
- Dimensionamos as instâncias de acordo com o seu perfil de carga real, em vez de um tier de catálogo, pelo que a maioria das migrações resulta em menos máquinas, e melhor utilizadas.
Object Storage
- O que usamos no lugar
- Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
- Nota de engenharia
- Compatível com S3 em todas as opções.
Managed Databases
- O que usamos no lugar
- Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
- Nota de engenharia
- Para PostgreSQL e MySQL, as alternativas UE têm paridade de funcionalidades. Para MongoDB, o Atlas EU existe mas tem parent company nos EUA - self-hosted em infraestrutura da UE é a resposta soberana.
LKE (Linode Kubernetes Engine)
- O que usamos no lugar
- Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
- Nota de engenharia
- Os Helm charts transferem-se sem problemas. A configuração do ingress controller do LKE porta-se para o nginx-ingress standard sem alterações.
NodeBalancers
- O que usamos no lugar
- Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
- Nota de engenharia
- Load balancing L4/L7 padrão em todas as opções europeias.
Block Storage
- O que usamos no lugar
- Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.
- Nota de engenharia
- Snapshot de volume + restore é o padrão de migração standard; para workloads em produção, migração baseada em rsync com janelas de fallback em modo read-only.
DNS Manager
- O que usamos no lugar
- Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
- Nota de engenharia
- Exportação da zone a partir da Linode e importação para o novo provider.
Cloud Firewall
- O que usamos no lugar
- Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.
- Nota de engenharia
- Todos os provedores europeus oferecem regras de firewall cloud-native.
Linode Backups
- O que usamos no lugar
- Binadit Managed Cloud Platform. restic e pgBackRest para dados, Velero para o estado do Kubernetes, para storage isolado na UE.
- Nota de engenharia
- Para workloads em produção, Borg/restic com vault offsite hospedado na UE é o padrão soberano standard.
Akamai CDN integration
- O que usamos no lugar
- Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
- Nota de engenharia
- A força histórica da Akamai em CDN já não é uma vantagem competitiva no espaço soberano europeu.
Linode VLAN
- O que usamos no lugar
- Binadit Private Infrastructure. VLANs isoladas com WireGuard para acesso site-to-site e de operadores.
- Nota de engenharia
- Networking privado cross-VM em todas as opções UE.
Como migramos de Akamai Linode
Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.
-
Dias 1-2
Inventário
Liste Instances, Volumes, NodeBalancers, clusters LKE, zonas DNS. Mapeie quaisquer automações CLI/API da Linode que precisem de ser reescritas.
-
Dias 3-7
Substituição soft
DNS, Object Storage e backup vault movidos primeiro. Réplicas de base de dados pré-configuradas em managed DB na UE. CI/CD atualizado para fazer deploy em ambos os providers em paralelo.
-
Semanas 2-4
Cutover de Compute
Instâncias reprovisionadas em compute Binadit. Workloads do LKE migrados para Kubernetes na Binadit. Cutover de base de dados via replicação lógica. NodeBalancer substituído. Desativação do Linode após uma janela de verificação de 1 semana.
TCO a 5 anos em saídas da Linode: normalmente 30-50% mais barato, com as poupanças concentradas em compute e bandwidth. O "1TB de transferência incluída por Linode" foi historicamente uma vantagem de pricing. O compute na UE agora geralmente inclui muito mais transferência por servidor, o que representa o melhor negócio para workloads típicos.
Perguntas frequentes
A Akamai é agora proprietária da Linode - isso altera a análise de GDPR?
Vamos perder a simplicidade operacional pela qual escolhemos a Linode?
E quanto ao Kubernetes gerido especificamente?
Quanto tempo demora uma saída do Linode?
Podemos manter o nosso CDN se movermos o compute para vocês?
A equipa de suporte europeia da Linode muda alguma coisa?
Planeie a sua saída de Akamai Linode.
Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.