Uma startup de tecnologia está desenvolvendo uma plataforma de streaming que precisará armazenar petabytes de dados não estruturados, como vídeos, imagens e logs de aplicação. A equipe de arquitetura definiu que a solução não deve utilizar uma hierarquia tradicional de diretórios e pastas, mas, sim, um espaço de nomes plano (flat namespace), onde cada arquivo é tratado como uma unidade contendo o dado, um identificador único e metadados enriquecidos. Além disso, o acesso aos dados deve ser realizado programaticamente através de chamadas de API baseadas no protocolo HTTP (RESTful), como PUT e GET.

A arquitetura de armazenamento projetada para atender a esses requisitos de escalabilidade web e acesso via API é conhecida como:

Uma corte superior está redesenhando sua arquitetura de sistemas para suportar sistemas legados críticos ainda executados em data center próprio, novos serviços digitais com alta variabilidade de carga (portais, APIs abertas, painéis em tempo real), além de requisitos rígidos de conformidade, auditoria e soberania de dados.

Na proposta inicial, a área de TI contrapõe duas abordagens de alto nível:

• estratégia nativa (cloud-native), com serviços desenhados desde o início para consumir intensamente recursos de nuvem pública (contêineres orquestrados, funções serverless, filas e bancos gerenciados, observabilidade integrada etc.);
• estratégia híbrida, em que parte significativa da carga permanece em data center próprio ou em nuvem privada, com integração estruturada (túneis seguros, VPN, direct connect, replicação de dados) com a nuvem pública.

Considerando os trade-offs entre uma arquitetura nativa em nuvem e uma arquitetura híbrida nesse contexto, é correto afirmar que: