Armazenamento de objectos compatível com S3 para programadores africanos: sem surpresas na factura de egress

A avaliar alternativas ao Amazon S3? A API S3 é o padrão de facto para armazenamento de objectos — praticamente todas as ferramentas de programador trazem integração compatível com S3, e pegar em boto3 ou s3cmd é memória muscular para a maioria. Mas para as cargas que os programadores africanos tipicamente correm, o modelo de preços do fornecedor dominante é difícil de viver.

Uma biblioteca multimédia WordPress para um site a servir leitores nigerianos. Um backup de Postgres a ser restaurado para uma máquina de staging em Joanesburgo. Um serviço de vídeo on-demand para audiências no Quénia. Em todos os três, o custo dominante é o egress — largura de banda a sair do bucket para o consumidor ou o destino do restauro — e o preço de egress dos grandes fornecedores é genuinamente punitivo. As tarifas típicas situam-se entre 0,08 e 0,12 $/GB para os primeiros terabytes, descendo a escala petabyte, e mais altas a partir de deployments em regiões africanas. Uma página de produto e-commerce popular com algumas imagens pode perder centenas de dólares por mês em egress sem ninguém reparar até a factura chegar.

É este o intervalo que uma alternativa compatível com S3 pode preencher: a mesma API que os programadores já conhecem, a mesma classe de durabilidade, mas com um modelo de preços que não sangra na largura de banda.

O que uma verdadeira alternativa compatível com S3 precisa de entregar

Três requisitos técnicos e um comercial:

1. Compatibilidade com a API S3. Não «temos um object store com uma API diferente» — compatibilidade real com a API S3. O objectivo é que todos os SDKs, todos os pipelines CI/CD, todas as ferramentas de backup falem nativamente. Se tem de reescrever código para adoptar uma API diferente, o custo de transição anula as poupanças.
2. Durabilidade da mesma ordem de grandeza. O serviço líder anuncia 99,999999999 % (onze noves) de durabilidade via replicação multi-AZ. Uma alternativa não precisa de igualar isso exactamente — nove noves chegam para a maioria das cargas — mas precisa de estar na mesma conversa. Um NAS de uma única máquina com RAID-6 não qualifica.
3. Consistência leitura-após-escrita. O incumbente oferece consistência forte leitura-após-escrita desde 2020. Alternativas ainda em consistência eventual vão mordê-lo em qualquer workflow em que um objecto acabado de carregar é lido imediatamente — que é a maioria dos workflows.
4. Preço de largura de banda previsível. É todo o ponto. Se a alternativa medir a largura de banda a preços de hyperscaler, não há razão para mudar. Largura de banda incluída a preço fixo, ou um modelo por escalões claro, é o que faz as contas bater certo para cargas com audiência africana.

O armazenamento de objectos da AFRICLOUD como alternativa

A AFRICLOUD oferece armazenamento de objectos compatível com S3 a partir dos nossos centros de dados em Lisboa e Joanesburgo — as duas localizações onde operamos VMs cloud. O endpoint fala a API S3, pelo que as ferramentas existentes funcionam sem alterações: aws-cli com override de endpoint, boto3 com endpoint_url definido, rclone, Duplicati, o adaptador S3 de qualquer CMS moderno. A durabilidade é multi-réplica dentro do centro de dados; o padrão de acesso é idêntico aos serviços S3-compatíveis padrão.

Para cargas com audiência africana especificamente: servir media para utilizadores nigerianos, ganeses ou quenianos a partir do nosso endpoint de Joanesburgo encaminha via NAP Africa (o maior IXP do continente, com mais de 580 redes em peering) em vez de fazer o tráfego ressaltar para uma região distante. Para audiências europeias e norte-africanas, Lisboa é o caminho geograficamente mais curto — Marrocos, Tunísia e Egipto correm todos abaixo dos 70 ms a partir do nosso endpoint de Lisboa.

Onde o serviço líder continua a vencer

Três casos genuínos para ficar com o incumbente:

• Integração profunda do ecossistema. Se o seu pipeline depende de eventos de object-store a disparar funções serverless ou jobs de treino ML no mesmo ecossistema do fornecedor, migrar apenas o armazenamento de objectos cria egress cross-cloud que anula as poupanças.
• Entrega edge global. Um CDN fortemente integrado mais um object store dão-lhe presença edge continental com um clique. Se a sua audiência é globalmente distribuída e precisa de edge em todas as regiões, uma alternativa com menos PoPs é genuinamente mais lenta.
• Preço de arquivo frio. Para dados genuinamente frios acedidos menos de uma vez por ano, os níveis de deep-archive à volta de 0,001 $/GB/mês são difíceis de bater. Uma alternativa de armazenamento de objectos sem nível frio custa mais para este caso específico.

Caminho de migração

Para a maioria dos buckets de audiência africana, a migração é um único comando rclone sync e uma actualização de configuração ao nível da aplicação. Três passos:

1. Configurar rclone com ambos os endpoints S3-compatíveis, origem e destino. Um ~/.config/rclone/rclone.conf padrão com dois remotos.
2. Sincronizar o bucket. rclone sync origem:o-seu-bucket destino:bucket-destino --progress. O encargo de egress da origem é real (uma última factura à saída), portanto para buckets grandes, orce-o.
3. Actualizar a sua aplicação. Altere o URL do endpoint na sua configuração para apontar para o novo fornecedor. Para a maioria dos SDKs isto é uma única variável de ambiente ou uma linha de código (boto3.client("s3", endpoint_url=...)).

Teste primeiro com um bucket pequeno só-leitura, verifique que os padrões de acesso correspondem, e depois migre produção. Se estiver a usar URLs pré-assinados para downloads, verifique que funcionam contra o novo endpoint — devem funcionar, já que é a mesma API, mas a rotação de credenciais vale a pena verificar antes do corte.

Veja a nossa página de Object Storage para preços actuais e quickstart, ou contacte-nos para discutir os detalhes de migração para a sua carga.