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.

Estados Unidos Stack de substituição, apenas UE 11 serviços mapeados
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.

Não cumpre AWS · Azure · GCP · Região da UE

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.

Cumpre Stack gerida pela Binadit

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.

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

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

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

A Akamai é agora proprietária da Linode - isso altera a análise de GDPR?
Reforça o argumento da jurisdição dos EUA, não o enfraquece. A Akamai é uma corporação americana há muito estabelecida, com contratos significativos com o governo dos EUA (incluindo o DoD). A análise do CLOUD Act aplica-se à Akamai Technologies Inc. e a todas as subsidiárias, incluindo a Linode LLC. Desde a aquisição, "Linode" é a marca; a entidade legal que detém os seus dados faz parte do grupo Akamai.
Vamos perder a simplicidade operacional pela qual escolhemos a Linode?
Essa simplicidade vale a pena proteger, e trata-se sobretudo de velocidade de provisionamento, uma API previsível e um suporte que não passa por três níveis. Mantém as três coisas. Provisionamos com Terraform, pelo que uma nova instância é um merge request em vez de um clique numa consola, e fala com o engenheiro que gere o seu ambiente em vez de uma fila de espera. A troca que faz é ter menos regiões globais em troca de uma presença UE mais forte e jurisdição UE total.
E quanto ao Kubernetes gerido especificamente?
Gerimos Kubernetes por si, o que é o equivalente mais próximo do LKE com jurisdição total da UE. Para workloads de alta confiança ou air-gapped, o Talos Linux em hardware dedicado na UE é o padrão soberano por conceção; operamos isto para clientes.
Quanto tempo demora uma saída do Linode?
Para uma carga de trabalho típica (5-25 Linodes, um cluster LKE, Object Storage, Managed DB): 3-6 semanas decorridas. Com um parceiro de infraestrutura gerida: 2-4 semanas. A simplicidade de produto da Linode torna a migração invulgarmente limpa.
Podemos manter o nosso CDN se movermos o compute para vocês?
Sim. Um CDN é uma das poucas camadas que não operamos nós mesmos, pelo que a escolha continua a ser sua. Se o CDN estiver à frente de tráfego com dados pessoais, a sua jurisdição faz parte da sua análise Schrems II e diremos isso claramente. Quando pretende mudar, a Bunny.net e a KeyCDN são as opções da UE que mais frequentemente configuramos, e operamos os cabeçalhos de cache, a estratégia de purge e o origin shielding em qualquer dos casos.
A equipa de suporte europeia da Linode muda alguma coisa?
O suporte operacional de equipas na UE é ótimo para os tempos de resposta, mas não altera a jurisdição. Os dados estão sob o controlo da Akamai independentemente do nível de suporte que responde.

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.