Na NGINX, temos falado ao longo dos últimos anos sobre a necessidade de tornar as aplicações verdadeiramente modernas e adaptáveis — portáteis, nativas da nuvem, resilientes, escaláveis e fáceis de atualizar. Mais recentemente, dois conceitos ganharam destaque por facilitarem a criação e a entrega de aplicações modernas. O primeiro é Platform Ops, em que uma equipe de plataforma de nível corporativo seleciona, mantém, conecta e protege todas as ferramentas de que as equipes de desenvolvimento e DevOps precisam para realizar seu trabalho. O segundo é shift left, que significa integrar segurança, redes e monitoramento de nível de produção às aplicações nos estágios iniciais do ciclo de vida de desenvolvimento. Com isso, os desenvolvedores passam a ter mais responsabilidade por funções que antes pertenciam às equipes de ITOps, mas, ao mesmo tempo, ganham mais opções e autonomia para decidir exatamente como implementá-las.
Embora isso pareça bom, na prática é difícil implementar Platform Ops e aplicar a abordagem de “shift-left” às ferramentas de infraestrutura e operações. Um dos motivos é que cada vez mais aplicativos são implantados de forma altamente distribuída, em ambientes conteinerizados e usando um dos inúmeros mecanismos de orquestração do Kubernetes, cuja quantidade não para de crescer. As empresas também querem implantar seus aplicativos em vários ambientes sem ficarem presas às diferenças entre as nuvens e entre os ambientes de nuvem e locais.
Uma “imagem dourada” para aplicações modernas
Como é de se esperar, nossos clientes e nossa comunidade continuam recorrendo à nossa ajuda para superar os desafios que enfrentam. Eles querem aproveitar todos os benefícios, mas integrar todas as peças — segurança, redes, observabilidade e monitoramento de desempenho, escalabilidade — exige um trabalho considerável. Tornar a plataforma resultante robusta o suficiente para ambientes de produção exige ainda mais trabalho. Eles se perguntam: “Por que não existe uma ‘imagem de referência’ para aplicativos modernos que possamos implantar a partir de um único repositório?”
Essa é uma boa pergunta, e assumimos o desafio de encontrar uma boa resposta. Primeiro, reformulamos a questão em termos mais concretos. Acreditamos que nossos clientes e nossa comunidade estejam perguntando o seguinte: “Vocês podem nos ajudar a integrar diferentes produtos de software em um conjunto mais coeso, ajustar a stack para definir as configurações e os parâmetros corretos e nos poupar trabalho e transtornos? E podem facilitar a execução da aplicação em diferentes nuvens sem que seja necessário fazer grandes alterações de configuração devido às diferenças nos serviços e nas funcionalidades subjacentes?”
Vemos uma solução que realmente responda a essas questões como algo benéfico para toda a comunidade — não apenas para nossos parceiros em centenas de empresas e para todos os principais provedores de nuvem —, uma verdadeira situação em que todos ganham. O ideal é que a solução não seja um “brinquedo”, mas um código robusto, testado e pronto para ser implantado em aplicações de produção em execução em ambientes Kubernetes. E, francamente, queremos que qualquer pessoa possa simplesmente pegar nosso trabalho diretamente do GitHub.
Indo direto ao ponto, hoje, no NGINX Sprint 2.0, anunciamos o lançamento da nossa solução: a primeira versão da Arquitetura de Referência para Aplicações Modernas (MARA), uma arquitetura e um modelo de implantação de código aberto para aplicações modernas. Esperamos que você goste, use, copie e, melhor ainda, modifique ou crie um fork para aprimorar ou personalizar. Neste post, explicamos o que desenvolvemos e como funciona.
A Arquitetura de Referência para Aplicações Modernas da NGINX
Definição de aplicações adaptativas modernas
Primeiro, vamos definir a aplicação moderna e adaptável ideal. Ela pode ser composta por microsserviços, ser conteinerizada e seguir os princípios de design nativo da nuvem (baixo acoplamento, facilidade de escalabilidade e independência da infraestrutura) – mas isso não é obrigatório. Parte da filosofia das aplicações modernas consiste em projetar a arquitetura especificamente para aproveitar a abstração da infraestrutura. Essa definição é simples, mas importante, pois estabelece o modelo básico para todas as arquiteturas de referência.
Os principais pilares de uma arquitetura de aplicações moderna incluem portabilidade, escalabilidade, resiliência e agilidade.
- Portabilidade – É fácil implantar a aplicação em diversos tipos de dispositivos e infraestruturas, em nuvens públicas e em ambientes locais.
- Escalabilidade – O aplicativo pode aumentar ou reduzir sua capacidade de forma rápida e integrada para atender a picos ou quedas na demanda em qualquer lugar do mundo.
- Resiliência – O aplicativo pode realizar o failover de forma transparente para clusters recém-criados ou ambientes virtuais em diferentes regiões de disponibilidade, nuvens ou data centers.
- Agilidade – O aplicativo pode ser atualizado rapidamente por meio de pipelines automatizados de CI/CD; no mundo dos aplicativos modernos, isso também implica maior velocidade de desenvolvimento e implantações de código mais frequentes.
Projetando nossa arquitetura de referência
Queríamos criar uma plataforma que atendesse aos requisitos básicos da nossa definição de aplicações modernas e do nosso padrão de implantação. Além dos objetivos técnicos, queríamos demonstrar princípios modernos de design de aplicações e incentivar nossa comunidade a fazer implantações no Kubernetes. E sim, queríamos oferecer código que pudesse ser “aproveitado” por desenvolvedores e equipes de DevOps e Operações de Plataforma para experimentar, modificar e aprimorar. Em resumo, queríamos oferecer:
- Uma arquitetura Kubernetes pronta para produção, fácil de implantar e que não é apenas um brinquedo
- Uma plataforma que destaca como os produtos de parceiros funcionam no Kubernetes
- Um botão para facilitar a compilação e a implantação de um controlador de Ingress do Kubernetes
- Um ambiente de teste para futuras integrações de produtos e parcerias
- Uma estrutura de implantação modular
- Um único repositório de código aberto para simplificar a descoberta e a adoção
Estas são as escolhas de design e parceria que fizemos para a primeira versão da plataforma (para conhecer nossos planos para a próxima versão, consulte Muito mais integrações e mais flexibilidade na versão 2). Acreditamos firmemente que tornar nosso aplicativo de referência inclusivo para os parceiros é fundamental para promover o engajamento tanto dos parceiros quanto da comunidade.
- Desenvolvimento de código aberto – https://github.com/nginxinc/kic-reference-architectures/; criamos o repositório em colaboração com a comunidade NGINX/F5
- Destino da implantação – Amazon Elastic Kubernetes Service (EKS)
- Automação de infraestrutura como código – Python e Pulumi, que aceita receitas do Terraform e scripts de automação de praticamente todas as linguagens de programação populares
- Imagem do Ingress Controller – NGINX Plus pré-compilado para assinantes, NGINX Open Source pré-compilado no DockerHub, e qualquer uma das versões compilada a partir do código-fonte
- Gerenciamento de logs (armazenamento e análise) – Elastic, por ser muito popular entre nossos usuários
- Monitoramento de desempenho e painéis – Prometheus e Grafana
- Desenvolvimento contínuo (CD) – Spinnaker
- TLS – cert-manager
- Aplicativo de demonstração – Google Bank of Anthos
Como o código é implantado
Para instalar e implantar o aplicativo de exemplo, basta executar um único comando para iniciar o script de inicialização. Em seguida, os projetos Pulumi abaixo são executados na ordem indicada. Cada nome de projeto corresponde ao nome de um diretório relativo ao diretório raiz do repositório. Para obter detalhes, consulte o arquivo README.
vpc - Defines and installs VPC and subnets to use with EKS └─eks - Deploys EKS
└─ecr - Configures ECR for use in EKS cluster
└─kic-image-build - Builds new NGINX Ingress Controller image
└─kic-image-push - Pushes image built in previous step to ECR
└─kic-helm-chart - Deploys NGINX Ingress Controller to EKS
cluster
└─logstore - Deploys Elastic log store to EKS cluster
└─logagent - Deploys Elastic (filebeat) logging agent to
EKS cluster
└─certmgr - Deploys cert-manager.io Helm chart to EKS
cluster
└─anthos - Deploys Bank of Anthos application to EKS
clusterMuito mais integrações e flexibilidade na versão 2
Reconhecemos que nosso esforço inicial talvez não ofereça todas as integrações necessárias para o seu ambiente Kubernetes. Platform Ops envolve escolhas inteligentes — mas não ilimitadas. Para facilitar a experimentação e a possível adoção da nossa nova plataforma de referência pelas equipes de Platform Ops, DevOps e desenvolvimento, planejamos implementar diversas melhorias em breve, incluindo:
- Configurar ambientes Kubernetes no Digital Ocean, OpenShift, Rancher, vSphere e em outras plataformas
- Integre-se ao NGINX Controller> para gerenciar e monitorar o NGINX Plus Ingress Controller[Editor – O NGINX Controller agora é o F5 NGINX Management Suite.]
- Forneça uma configuração pronta para uso para o NGINX App Protect
- Integre-se a produtos e serviços da F5, como BIG‑IP, Cloud Services e Volterra
- Integre-se ao NGINX Service Mesh e ao Aspen Mesh baseado no Istio
- Integre-se nativamente ao Terraform e a outras ferramentas de automação
- Ofereça suporte a outras opções de CI/CD
- Implante clusters separados ou múltiplos para serviços de infraestrutura e de aplicações
Esperamos que nosso trabalho possa se tornar uma estrutura para outras plataformas de referência e um ponto de partida “reutilizável” para desenvolver todos os tipos de aplicações modernas diferenciadas. Como o Kubernetes é um mecanismo extremamente poderoso tanto para criar aplicações modernas quanto para capacitar as equipes de operações de plataforma e promover a cultura shift-left, quanto mais abrangente e modular for nossa arquitetura de referência, melhor. Estamos ansiosos para saber o que vocês, da comunidade, acham do nosso trabalho e, mais importante, o que criarão com ele.
Comece a usar a arquitetura de referência
Baixe nossa plataforma de referência e experimente-a. Conte-nos o que você achou e o que gostaria que desenvolvêssemos em seguida. Pull requests são mais do que bem-vindos. Estamos ansiosos para colaborar com você na próxima geração de aplicações modernas, adaptáveis e “reutilizáveis”, que contribuam para a comunidade e para todos os desenvolvedores.
Posts relacionados
Este post faz parte de uma série. À medida que adicionamos novos recursos ao MARA, publicamos os detalhes no blog:
- Uma nova arquitetura de referência de código aberto para aplicações modernas (este post)
- Integração do OpenTelemetry à arquitetura de referência para aplicações modernas – um relatório de progresso
- MARA: agora em execução em uma estação de trabalho perto de você
- Anunciando a versão 1.0.0 da Arquitetura de Referência para Aplicações Modernas do NGINX
Sobre o autor
Publicações relacionadas no blog

Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.

Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.

Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.

Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.