5 Princípios Fundamentais de Aplicações Modernas

5 Princípios Chave para Aplicações Modernas em Plataformas Híbridas

Em uma recente discussão de painel intitulada “Top 5 Criteria to Choose the Right Platform for Your Modern Workloads” (Os 5 Principais Critérios para Escolher a Plataforma Certa para Suas Cargas de Trabalho Modernas), membros da equipe do VMware Cloud Foundation (VCF) e o analista Brent Ellis da Forrester exploraram como as empresas avaliam plataformas de infraestrutura para cargas de trabalho modernas e híbridas.

A conversa se concentrou em cinco prioridades: segurança e resiliência, escalabilidade, simplicidade operacional, capacitação de desenvolvedores (developer enablement) e inovação. Ellis, da Forrester, enfatizou que as organizações estão buscando padronização na engenharia de plataformas (platform engineering), com plataformas que tratam VMs e cargas de trabalho Kubernetes de forma igualitária. Este é um princípio central de design do VMware Cloud Foundation 9.0.

Esta discussão estabeleceu as bases para entender por que as escolhas de plataforma são importantes, especialmente para private clouds. Vamos agora aprofundar cinco princípios chave para projetar e operar com sucesso aplicações modernas, utilizando as melhores práticas do NIST, CNCF, Google SRE e ITIL.

Estrutura para Construir, Executar e Gerenciar Aplicações para a Próxima Década

Aplicações modernas não estão mais confinadas a máquinas virtuais, containers ou contas de cloud. Elas abrangem runtimes, data centers, enterprise edges e múltiplas clouds, cada um com seus próprios requisitos operacionais, todos interligados por uma API e algum nível de automação. O desafio não é simplesmente onde essas aplicações rodam, mas como as organizações podem garantir que elas sejam seguras, resilientes, observáveis e escaláveis.

Ao longo da última década, a indústria convergiu em um conjunto de padrões arquitetônicos e operacionais que definem o que significa ser moderno. Esses padrões vão além dos recursos de produtos. Eles são princípios de engenharia enraizados em padrões abertos, práticas de SRE e na experiência prática de profissionais que implementaram aplicações em escala.

5 Princípios Chave de Aplicações Modernas

1. Arquitetura Cloud Native, Composable e API-First

Esperamos que as aplicações modernas sejam elásticas, resilientes e com ciclos de vida gerenciados intensivamente (heavily lifecycled). As definições da indústria para “cloud native” convergem para as mesmas ideias básicas: aplicações construídas para aproveitar a infraestrutura de cloud através de serviços fracamente acoplados (loosely coupled services), APIs e serviços gerenciados.

O princípio arquitetônico central por trás das aplicações cloud native é a composibilidade (composability), que envolve dividir capacidades em serviços independentemente implementáveis com APIs (ou events) bem definidas. Em sua essência, composibilidade significa que capacidades individuais são tratadas como unidades que você pode conectar sem necessariamente conhecer seus detalhes internos.

Em aplicações empresariais, cada capacidade está alinhada a uma função de negócio. Na camada de aplicação, essas capacidades podem ser algo como Perfil do Cliente, Processamento de Pagamentos, Inventário, Motor de Recomendação (Recommendation Engine), Chatbot, etc. Cada uma dessas capacidades deve ser:

• Exposta via uma API e acompanhada por uma especificação declarativa (declarative spec).
• Independentemente implementável (ciclo de vida separado/único).
• Versionada e governada como um produto (cada uma tem seus próprios SLAs, documentação, proprietário).

Na camada de plataforma, as capacidades se parecem com:

• “Me dê um cluster Kubernetes com esta topologia nesta região.”
• “Provisione uma VM a partir de uma gold image, nesta zona, usando esta política de storage.”
• “Provisione um banco de dados MS SQL com persistent storage.”
• “Anexe um load balancer e um VIP na frente desta aplicação.”

A composibilidade permite que você gerencie o ciclo de vida de uma capacidade ou serviço sem reimplementar toda a aplicação e todas as suas dependências. Você pode escalar componentes independentemente, isolar falhas e usar códigos e/ou runtimes variados onde fizer sentido. A composibilidade transforma a plataforma em um catálogo programável.

Arquitetura API-First

O design API-first é o que torna essa composibilidade confiável. Seguindo essa disciplina, as equipes de desenvolvimento definem a especificação da API (API spec) (ou Kubernetes CRD) e os detalhes funcionais para seus respectivos serviços antecipadamente. Isso é chamado de contract (contrato). Os serviços são subsequentemente integrados através desses contratos – e não acessando diretamente o banco de dados ou as implementações internas de um serviço adjacente.

Do ponto de vista da plataforma, o VMware Cloud Foundation (VCF) 9.0 se alinha a este modelo, tornando-o fortemente API-first. O VCF expõe seus serviços nativos através de interfaces baseadas em API e as invoca para integrar as muitas partes móveis que se unem para entregar o todo. Isso significa que o mesmo tooling de CI/CD ou GitOps usado para código de aplicação pode provisionar programaticamente domínios de carga de trabalho (workload domains), clusters, redes, storage e blueprints.

2. Entrega e Operações Declarativas, Orientadas por GitOps

Nos últimos 3-4 anos, a indústria se estabeleceu em grande parte na configuração declarativa com reconciliação contínua como a linha de base para o provisionamento e gerenciamento do ciclo de vida de aplicações modernas. Essa linha de base é o que deu origem ao GitOps.

A iniciativa OpenGitOps do CNCF destaca quatro princípios centrais:

• Declarativo: Descrever todo o sistema de forma declarativa.
• Versionado e Imutável: Armazenar o estado desejado no Git.
• Puxado Automaticamente (Pulled Automatically): Usar agentes de software para reconciliar.
• Continuamente Reconciliado: Observar e reaplicar o estado desejado em caso de drift (desvio).

No GitOps, o Git é a fonte da verdade para o estado desejado da infraestrutura e da aplicação, com agentes reconciliando continuamente os sistemas ativos para esse estado. Adotar uma metodologia GitOps oferece benefícios mensuráveis – ambientes reproduzíveis e “carimbados” (rubber stamped), rollbacks mais simples, histórico completo de auditoria de mudanças e um ponto de integração natural para policy-as-code, para citar apenas alguns. Um resultado bônus para ambientes regulamentados é a auditabilidade, especialmente quando combinada com práticas de DevSecOps.

Os riscos de ignorar isso também são claros – ambientes desonestos (rogue environments), hotfixes manuais, pipelines frágeis e pontos cegos de segurança sobre “quem mudou o quê, onde e quando”. Uma estatística do CNCF publicada em 2022 mostra que organizações cloud-native maduras tinham cerca de 4 vezes mais chances de seguir práticas de GitOps do que pares menos maduros.

Um exemplo clássico é uma aplicação bancária rodando em Kubernetes em múltiplas regiões. Todos os objetos Kubernetes, políticas de rede e até mesmo alguns recursos do lado da cloud são declarados e armazenados no repositório Git de escolha. Novas promoções de código fluem de dev → staging → prod via pull requests. Um controlador GitOps (por exemplo, Argo CD) aplica continuamente as mudanças e reporta qualquer configuration drift.

Com essa configuração, as equipes de auditoria podem inspecionar o histórico do Git em vez de buscar conhecimento de código, e os rollbacks estão a apenas um commit de distância, em vez de uma caixa de Pandora de runbooks de emergência e shell scripts. Uma métrica chave para medir o sucesso é a taxa de falha de mudança (change failure rate) e o tempo médio para restauração (MTTR). Quanto menor o MTTR, melhor.

O VCF 9.0 é essencialmente um playground GitOps para private cloud. A interface de consumo unificada significa que desenvolvedores e engenheiros de plataforma podem acessar um único endpoint usando IaC (Infrastructure as Code) (por exemplo, YAML, Terraform) ou REST para configurar tudo, desde domínios de carga de trabalho de destino até stacks de banco de dados e serviços de Private AI. Isso é seguido por um blueprint de Automação VCF que provisiona Namespaces, VMs, clusters VKS e load balancers de forma declarativa. A partir daí, o Argo CD trata os clusters VKS como qualquer outro alvo Kubernetes conforme, puxando manifestos de aplicação do Git e reconciliando namespaces, deployments, serviços e políticas. É aqui que o VCF 9.0 realmente brilha como uma plataforma de aplicação moderna – ele permite que você execute sua private cloud com o mesmo modelo operacional declarativo e centrado no Git que o ecossistema CNCF provou ser eficaz na public cloud.

3. Observability e Automação de Ciclo Fechado (Closed-Loop Automation)

Aplicações e seus respectivos serviços de infraestrutura gerarão continuamente uma vasta quantidade de dados de telemetria diversos – métricas, logs, traces, events – todos os quais devem ser coletados, correlacionados e traduzidos em informações utilizáveis. Os dados de telemetria devem ser usados de forma sistemática para impulsionar decisões, em vez de apenas depurar interrupções.

Os Objetivos de Nível de Serviço (SLOs) são a forma como você traduz toda essa telemetria em informações que realmente importam para o negócio. Em vez de “a CPU está alta” ou “estamos vendo latência”, os SLOs definem objetivos centrados no usuário, como “99,9% das consultas de conta são consistentemente concluídas em menos de 500ms”. Os SLOs também determinam uma tolerância permitida para falhas, mantendo as expectativas.

Os SLOs fornecem uma maneira de decidir quando lançar recursos nice-to-have versus investir em confiabilidade (por exemplo, correções de bugs) e na experiência do usuário. Eles podem ser conectados a políticas que automatizam decisões – escalando uma camada de aplicação, pausando rollouts, acionando um rollback, alterando prioridades de backlog, etc.

Tooling e Instrumentação

Garantir uma implementação consistente de coletores de telemetria também é crucial. Felizmente, isso pode ser simplificado usando os mesmos processos GitOps adotados para lançar código. Pipelines de métricas, dashboards, regras de alerta, definições de SLO e runbooks podem todos residir no Git da mesma forma que seus manifestos e blueprints.

Controladores GitOps e pipelines CI/CD configuram coletores de telemetria (por exemplo, Prometheus, agentes OpenTelemetry), os conectam ao seu cluster e cargas de trabalho VM, e enviam configurações de alerta para sua plataforma de observability. Isso permite uma estratégia de telemetria versionada, declarativa e testável que pode ser atualizada e implementada como qualquer código.

Quando combinada com os dados de observability, você obtém o ciclo fechado. O VCF 9.0 fornece um feedback loop entre observability e automação. Descobertas de diagnóstico, pontuações de saúde (health scores) e drift events do VCF Operations podem ser expostos como fontes de dados para workflows de Automação VCF. Por exemplo, um SLO violado repetidamente em uma camada de serviço específica pode iniciar um workflow de planejamento de capacidade ou abrir uma solicitação de mudança para escalar um worker pool VKS ou atualizar a política vSAN de apoio.

Como tudo isso é exposto através das APIs do VCF, você pode construir um “GitOps orientado por observability” onde a telemetria e o estado do SLO influenciam as tarefas de automação. Isso pode incluir promoção de código, escalonamento, mudanças de infraestrutura, etc. Para engenheiros de GitOps e plataforma, este é verdadeiramente o objetivo final para observability – um ciclo fechado onde os dados impulsionam a ação em toda a stack VCF. Não apenas gráficos bonitos.

4. Zero-Trust Security, Compliance e Resiliência por Design

O Zero-Trust no contexto de aplicações modernas começa com uma suposição clara – nada é confiável apenas por causa de onde existe na stack ou como chegou lá. Nem o código, pod, node, rede, volume ou usuário. Cada requisição deve ser explicitamente autenticada, autorizada e inspecionada, e o movimento lateral deve ser rigidamente restringido.

O whitepaper de segurança do CNCF e a recente orientação de segurança do Kubernetes enfatizam que em arquiteturas de microsserviços, o perímetro real é a própria carga de trabalho, e que o Zero-Trust é implementado através de camadas de identidade, política e verificação contínua, não um único firewall mágico. Na prática, isso significa identidade da carga de trabalho, autenticação forte em cada salto (hop), segmentação de rede granular e privilégio mínimo agressivo (least-privilege) para pods, service accounts e acesso Git.

Para o GitOps, o Zero-Trust só funciona se for declarativo e automatizado. Identidade, políticas de rede, restrições de segurança de pod e políticas de admissão precisam residir no Git ao lado de manifestos de aplicação e configurações de plataforma, enquanto serviços adjacentes garantem que apenas cargas de trabalho assinadas e em conformidade com a política sejam reconciliadas nos clusters Kubernetes.

VCF e Zero-Trust

Embora haja muito a considerar, não precisa ser difícil. O VCF 9.0 fornece uma stack de segurança abrangente para implementar o Zero-Trust. Na camada de rede, o VCF Networking (NSX) oferece microssegmentação e firewalling distribuído com granularidade por VM/por vNIC, e com a adição do serviço avançado vDefend, ele adiciona IDS/IPS e prevenção de malware para impor políticas Zero-Trust no tráfego east–west.

Os novos construtos de Virtual Private Cloud (VPC) permitem que você crie ambientes de rede isolados e multi-tenant com roteamento personalizado e políticas de segurança, o que é essencialmente uma implementação de Zero-Trust no limite do domínio (ou VPC). E na camada de runtime da aplicação, o VKS pode impor políticas de rede e de nível de cluster do Kubernetes para manter a comunicação pod-to-pod rigidamente controlada, alinhando-se à orientação do CNCF de que a política de rede é um dos principais controles Zero-Trust no Kubernetes.

5. Platform Engineering como Fundação

De todos os princípios delineados neste artigo, o Platform Engineering se destaca como o mais transformador para uma organização que constrói e gerencia aplicações modernas. Platform engineering é a disciplina de projetar e construir cadeias de ferramentas (toolchains) e workflows que permitem capacidades de autoatendimento para desenvolvedores.

Em certo sentido, o Platform Engineering é a evolução (ou resultado) do DevOps tradicional, passando de metodologias abstratas para uma entrega mais concreta, como estabelecer as bases para a Internal Developer Platform (IDP). O objetivo do Platform Engineering não é criar barreiras de infraestrutura ou retornar aos dias de operações de TI rígidas. Em vez disso, ele é projetado para reduzir a carga cognitiva do desenvolvedor – e o burnout associado – comumente causado pela adoção do DevOps.

Em vez de esperar que cada desenvolvedor compreenda as complexidades únicas de uma plataforma de aplicação moderna específica – runtime, serviços de dados, rede, segurança, especificidades exigidas pela empresa – para construir/executar suas aplicações, a equipe de Platform Engineering constrói uma IDP que fornece “Golden Paths” (também conhecidos como “Paved Roads”) acordados para consumo. Um Golden Path é um workflow opinativo, governado e automatizado para construir e implantar uma aplicação em um determinado ambiente. Estas são rotas padronizadas para a produção que abstraem a complexidade, ao mesmo tempo que fornecem a autonomia desejada pelo desenvolvedor.

Componentes de Platform Engineering (alto nível)

O VCF 9.0 fornece todos os blocos de construção para realmente implementar esses golden paths com ferramentas e serviços familiares:

• O VCF Automation foi reimaginado para ser o motor de “plataforma como um produto” (platform as a product).
• Os Blueprints permitem que os Engenheiros de Plataforma definam topologias complexas de aplicações e serviços em uma UI ou de forma declarativa. Esses blueprints podem então ser publicados em um catálogo de autoatendimento para que os usuários do projeto possam solicitar ambientes complexos com uma única ação ou chamada de API.
• O vSphere Kubernetes Service (VKS) se conecta a isso como o runtime Kubernetes, dando às equipes de plataforma um cluster conforme e com ciclo de vida gerenciado que pode ser consumido diretamente do VCF Automation ou programaticamente.
• O VMware Data Services Manager (DSM) e os serviços integrados de rede e ingress do VCF fornecem as peças para oferecer “cluster abc”, “banco de dados xyz” e “stack de aplicação 123” como itens de catálogo distintos para desenvolvedores.
• O amplo suporte do VCF para GitOps e o extenso tooling de código aberto garantem que os desenvolvedores possam realizar suas tarefas usando ferramentas e serviços familiares.

Resumo

O provisionamento, execução e gerenciamento de aplicações modernas exigem um afastamento radical dos processos manuais e orientados por tickets do passado. Os cinco princípios críticos destacados aqui – Arquitetura Composable, GitOps Declarativo, Observability e Automação de Ciclo Fechado, Zero-Trust Security e Platform Engineering – formam uma estrutura interligada que permite às empresas sobreviver e prosperar em um mundo definido por software.

O VCF 9.0 serve como uma manifestação tecnológica desses princípios, entregando uma plataforma de private cloud unificada que possibilita o modelo “Platform as a Product”. Ao alavancar o VCF 9.0 para construir Internal Developer Platforms robustas, as organizações podem alcançar o equilíbrio difícil de velocidade do desenvolvedor (developer velocity) e governança empresarial.