Cuca Fresca IT

Na semana passada, acompanhei o Nutanix Next 2026 em Chicago representando a LGTI. Este foi o meu primeiro Next e a dinâmica do evento me surpreendeu. Logo no momento de montar a agenda, ficou claro que era possível seguir uma trilha puramente técnica, focar em negócios ou simplesmente transitar livremente entre as duas áreas. Essa flexibilidade é rara em conferências desse porte e a experiência foi muito positiva. Hoje dou início ao primeiro texto de uma série de três artigos, onde vou falar sobre os pontos operacionais e de desenho de ambiente que mais chamaram a minha atenção. E já deixo o aviso: o destaque aqui não será o ruído em torno de Inteligência Artificial, mas sim o impacto real na fundação da infraestrutura.

Sessão 1: Navigating Digital Sovereignty: Strategies for Modern Enterprises

A premissa da sessão definiu a soberania digital como um requisito de infraestrutura corporativa, e não apenas uma exigência governamental. O impacto para o desenho do ambiente é claro: soberania não é um módulo adicional. Como demonstrado logo nos primeiros slides da apresentação, se isso não for planejado na arquitetura desde o início, o custo se torna proibitivo e a implementação se torna impossível de ser readaptada posteriormente.

O modelo apresentado dividiu o conceito em quatro requisitos técnicos:

• Soberania de Dados: Controle estrito sobre onde a informação reside, como ela se move e sob quais condições é acessada.
• Soberania Operacional: Autonomia sobre quem opera a plataforma, garantindo a administração contínua sem depender de entidades externas para o dia a dia ou respostas a incidentes.
• Soberania Técnica: Capacidade de evitar dependências irreversíveis de planos de controle, interfaces ou modelos operacionais de um único provedor.
• Soberania de Resiliência: A capacidade de recuperar e continuar operando com a governança intacta durante falhas, incidentes cibernéticos ou degradação de conectividade.

O verdadeiro calcanhar de Aquiles da soberania digital, no entanto, não está apenas nos grandes contratos de nuvem, mas na dinâmica interna desenfreada das corporações. Hoje, a área de negócios tem uma ideia, a equipe de desenvolvimento provisiona containers e código de forma acelerada, e ainda temos o advento da IA ingerindo dados de fontes não mapeadas. A pergunta central “onde está o meu dado e como estou cuidando dele?” é frequentemente ignorada pela maioria, que opera como se o problema não existisse. Essa conta de risco pode demorar, mas ela vai chegar.

Essa realidade de campo se conecta diretamente com os três cenários comuns de falha exibidos na sessão, que mostram exatamente por que a soberania não escala na prática:

• Design focado apenas em Residência: Limitar a estratégia de soberania à localização física do dado (“meu dado está no meu país ou no meu prédio”) é uma falha de planejamento. Como destacado na sessão, se o projeto focar unicamente na residência geográfica e pular os demais controles operacionais, a equipe inevitavelmente esbarrará em um muro de complexidade durante momentos de pressão. Soberania exige que a infraestrutura seja administrável sob estresse, e não apenas que ela tenha um endereço físico local.
• Governança Fragmentada: A dispersão de controles de identidade, segurança e auditoria em ferramentas isoladas torna a gestão de conformidade um processo ineficiente. Sem uma visão centralizada, a equipe de TI perde a capacidade de aplicar políticas de forma uniforme, o que gera lacunas de segurança e dificulta a manutenção do padrão operacional em todas as camadas da infraestrutura.
• Colapso do Day 2: A governança falha na rotina operacional se depender de documentação estática ou processos manuais. Durante o ciclo de vida do ambiente, seja em migrações, atualizações de sistema ou mudanças na equipe técnica, a arquitetura acaba perdendo a conformidade. Para que a operação não quebre o desenho original de soberania, a validação do ambiente precisa ser automatizada e contínua.

Na fase de implementação, para evitar esse colapso, os requisitos foram mapeados diretamente nos componentes do portfólio Nutanix:

• Consistência Operacional e Multicloud: O NCI e o NCM fornecem um control plane unificado, preservando o modelo operacional no cluster local ou nas instâncias no NC2.
• Governança de Acesso: O IAM e o RBAC nativos aplicam o princípio do menor privilégio e a separação de funções centralizada.
• Isolamento de Rede: A microsegmentação e as zonas de confiança explícitas são geridas via Flow.
• Criptografia e Localidade: O Nutanix Native KMS gerencia a proteção dos dados em repouso, garantindo que a custódia das chaves permaneçam sob controle direto da equipe de TI no ambiente local, sem depender obrigatoriamente de serviços externos para a operação básica.
• Resiliência em Escala: Integração de disaster recovery e cyber recovery, garantindo que as métricas de RPO e RTO subam intactas junto com as políticas de proteção.

O fechamento da sessão focou na realidade da operação. O principal ponto destacado foi que a plataforma Nutanix não garante a soberania de forma automática, mas reduz o custo operacional de aplicá-la corretamente. Ao embarcar as primitivas de governança diretamente no hypervisor e no plano de gerência, a arquitetura consegue alinhar a intenção do desenho inicial com a realidade do dia a dia, entregando os blocos estruturais para que a equipe de TI evite o colapso dos dados.

Sessão 2: From SDDC to Simplicity: Why a Unified Control Plane is the Future of IT

A segunda sessão foi direto ao ponto para quem atua na operação da infraestrutura. A apresentação foi conduzida por um engenheiro que fez a transição da VMware para a Nutanix, e o tom foi exatamente o que procuro em eventos técnicos: foco na resolução de problemas reais, sem discurso comercial e focado na realidade nua e crua do ambiente corporativo.

A discussão abordou a transição estrutural que o mercado de virtualização está enfrentando com as atualizações de licenciamento e o novo formato do VCF 9. O debate contornou a briga de preço por core e atacou o impacto operacional de longo prazo e a dívida técnica atrelada ao desenho base do ambiente.

O ponto central do palestrante foi claro: não existe tecnologia milagrosa, mas existe arquitetura inteligente. Ele evidenciou a diferença entre um ambiente que tenta ser integrado por terceiros e um que já nasceu unificado.

O contraste apresentado nos slides mapeou exatamente onde a complexidade e os gargalos residem:

• O modelo legado de SDDC: A operação exige a sincronização contínua de múltiplos componentes stateful. Na prática, a equipe de TI precisa gerenciar diversas consoles, metadados fragmentados, vários bancos de dados isolados e uma teia de APIs tentando conversar entre si para alinhar gerência central, rede definida por software e automação. O resultado é um ecossistema suscetível a falhas de estado. Muito tempo é gasto desenvolvendo scripts e lógicas de reconciliação apenas para manter tudo funcionando em conjunto.
• A integração no Dia 0: O modelo da Nutanix substitui essa orquestração externa por um control plane nativo. A fundação do sistema centraliza a gerência em um banco de dados distribuído unificado. A plataforma funciona de forma orgânica desde a sua concepção, sem precisar de adendos.

Com uma fonte única de configuração, a dependência de sincronia entre ferramentas isoladas desaparece. Os Nodes do cluster operam sob uma regra estrita onde não conseguem gerar um estado local divergente do control plane central. Eles apenas consultam o banco unificado e aplicam a política em tempo real.

O resultado prático dessa mudança de topologia altera substancialmente a recuperação de desastres do próprio plano de gerência. Restaurar o painel de controle de um SDDC legado a partir de um backup é um processo denso, pois demanda o realinhamento de estado de vários bancos de dados assíncronos para evitar corrupção lógica. No modelo unificado, a recuperação do Prism Central é basicamente a restauração de um único banco de dados, o que simplifica a execução e reduz a janela de indisponibilidade em cenários de falha na administração.

Essa simplificação influencia diretamente a topologia física. Em ambientes baseados em componentes distribuídos legados, as equipes de TI tendem a projetar clusters enormes para evitar a criação de novos domínios de gerência e seus respectivos bancos de dados, o que dificulta as janelas de manutenção e amplia o raio de impacto em caso de falhas. Com um control plane centralizado, a infraestrutura permite a operação de múltiplos clusters menores. A distribuição de cargas é gerida pela plataforma de forma unificada, viabilizando atualizações granulares de Nodes e de software sem gerar paradas no ambiente produtivo.

O resultado prático dessa mudança de topologia altera substancialmente o ciclo de vida do ambiente. Em modelos legados, cada atualização exige a validação de uma matriz de compatibilidade complexa entre diferentes versões de gerência, rede e storage. No modelo unificado, o Lifecycle Manager (LCM) executa o inventário e a atualização de todo o stack em um fluxo único. Isso garante que o estado do banco de dados distribuído permaneça íntegro sem a necessidade de intervenções manuais para reconciliar versões de componentes isolados, eliminando o risco de falhas de estado durante as janelas de manutenção.

Sessão 3: SuperSession Inside AOS Architecture

A última sessão do dia desceu ao nível mais baixo da arquitetura do AOS, detalhando como o design estrutural de metadados define o limite de performance e a escalabilidade de todo o ambiente. Em arquiteturas legadas, o uso de designs ineficientes de metadados cria gargalos de processamento que sufocam a infraestrutura durante picos de acesso. O modelo adotado resolve esse atrito operando com uma gestão distribuída e altamente otimizada, o que elimina as múltiplas camadas de tradução típicas de file systems tradicionais que historicamente penalizam o fluxo de I/O.

A evolução mais recente dessa arquitetura consolida a maturidade do control plane unificado abordado anteriormente. O coração do sistema permanece sendo a CVM, orquestrando as requisições de leitura e escrita sob a mesma lógica de controle distribuído. A mudança estrutural é que a plataforma agora consegue desacoplar a camada de armazenamento de forma transparente e estender essa orquestração para arrays externos de classe corporativa. É aqui que entram as integrações nativas com Dell PowerStore, Dell PowerFlex e os appliances da Pure Storage. Para o hypervisor, torna-se irrelevante se o dado está gravado em um disco NVMe embarcado localmente no Node ou se repousa em um volume entregue por um PowerFlex ou Pure Storage via rede.

O segredo para não perder performance nesse desenho é a gestão de metadados. A plataforma opera com um anel de metadados distribuído e tolerante a falhas, o que elimina o gargalo comum de bancos de dados relacionais centralizados que frequentemente degradam em escala. Além disso, ao consumir storage externo, o AHV simplifica a conectividade ao gerenciar o multipathing de forma nativa. Isso remove a necessidade de softwares ou módulos de terceiros para o roteamento de I/O, garantindo que a comunicação entre o hypervisor e as controladoras físicas do array ocorra pelo caminho mais eficiente e com menor latência possível.

O ganho prático e imediato dessa arquitetura focada em metadados aparece na sustentação de cargas críticas. O processamento de snapshots, por exemplo, é resolvido inteiramente na camada lógica do sistema. O congelamento da máquina virtual cai para praticamente zero, viabilizando rotinas de proteção para bancos de dados massivos sem interromper a produção ou derrubar a performance geral do array físico. Em paralelo, a manutenção do disco e o garbage collection rodam como processos analíticos em background, validando referências lógicas e recuperando espaço em disco sem disputar recursos com a carga de trabalho principal.

A flexibilidade da arquitetura se prova ao suportar nós dedicados exclusivamente ao processamento. Nesses cenários com armazenamento externo, a plataforma tira o AOS do caminho de dados de forma intencional. O AHV consome os volumes diretamente de infraestruturas robustas como Dell PowerStore, PowerFlex ou Pure Storage através de protocolos de baixíssima latência. Toda a inteligência de metadados, proteção de dados físicos e processamento de I/O é delegada para as controladoras desses arrays externos.

O desenho permite ao ambiente estender a sua capacidade e utilizar o hardware ideal para cargas específicas, sem gerar silos de administração. A governança e a gestão do ciclo de vida das máquinas virtuais continuam centralizadas no Prism. Essa abordagem atesta a visão técnica do evento: centralizar a gerência de forma absoluta, descentralizar a execução física da maneira que for mais estratégica para a performance e garantir que a equipe de TI não pague a conta de gerenciar a complexidade.

No fechamento desse primeiro dia, a conclusão é direta: a plataforma Nutanix se consolida na fundação do ambiente para resolver problemas estruturais, independente do momento atual da sua infraestrutura ou do direcionamento do seu negócio. Não existe solução miraculosa, o que existe é inteligência de arquitetura e software.

No próximo artigo desta série, a cobertura avançará para novos cenários operacionais. Vamos analisar sessões focadas em casos de clientes reais executando a solução em produção. É o momento de mergulhar na realidade ver a tecnologia rodando na prática, o exato território onde a arquitetura sólida prevalece e as promessas superficiais do mercado costumam desmoronar.