Uma agência governamental nacional na Holanda com uma gama diversificada de partes interessadas e usuários queria mover seus fluxos de trabalho de processos baseados em papel para uma infraestrutura digital moderna. Isso permitiria que a agência se movimentasse mais rapidamente e simplificasse a vida de seus usuários e funcionários.
O desafio? A agência permitiu que cada localidade participante criasse processos e requisitos um tanto quanto exclusivos. Inicialmente, a agência fez um grande esforço para criar um aplicativo monolítico completo com inúmeras personalizações. O primeiro esforço falhou sob o peso da hiperpersonalização – “morte por mil requisitos”. A HCS Company , uma consultoria de TI holandesa especializada em tecnologias de código aberto e Red Hat®, foi escolhida para testar novas maneiras de digitalizar os processos da agência com uma abordagem diferente.
A equipe de DevOps da agência trabalhou no projeto com Benoit Schipper, engenheiro líder de confiabilidade do site (SRE) da HCS. Juntos, eles começaram analisando mais profundamente o problema que estavam resolvendo. Usuários, desde funcionários do governo até advogados, contadores e cidadãos comuns, precisam fazer login no aplicativo da agência, verificar o status de um projeto ou processo e enviar um PDF. Benoit e a equipe decidiram construir uma base simples como ponto de partida para a solução. Benoit explica: “Nós olhamos para isso e dissemos: ‘Vamos fazer algo muito genérico e, para quaisquer solicitações especiais, podemos construir a partir dessa base genérica’”. A equipe de DevOps também queria preparar a fundação para o futuro, garantindo escalabilidade tanto dentro da infraestrutura existente quanto para locais e aplicativos adicionais que pudessem ser necessários no futuro.
Benoit e a equipe planejaram esse futuro e chegaram a uma nova arquitetura de front-ends (micro) muito pequenos que podem ser compostos em diferentes aplicativos mapeados para serviços pequenos e distintos (microsserviços) no back-end. “Optamos por microsserviços porque, com essa arquitetura, você está pronto para ir para a nuvem e escalar quando ela se tornar muito grande”, diz Benoit. “Nós separamos o quebra-cabeça em peças menores que poderíamos colar.”
A primeira decisão em torno da implementação foi migrar de servidores Microsoft Windows em um ambiente dedicado para um ambiente baseado em contêiner na nuvem, que é mais adequado para microsserviços componíveis e flexíveis. A equipe escolheu o Red Hat OpenShift® como plataforma de contêiner.
Havia dois fatores fortes a favor do OpenShift. Primeiro, a longa experiência da RedHat trabalhando com governos tornou fácil obter a aprovação governamental para o design. Em segundo lugar, o OpenShift inclui muitas ferramentas e aplicativos projetados para fácil construção e manutenção de microsserviços e arquiteturas de microsserviços, incluindo:
A migração para contêineres significou substituir o antigo back-end .Net da agência, que rodava em servidores Windows. Felizmente, foi uma transição fácil para o .Net Core , uma versão do .Net otimizada para contêineres. Um benefício adicional é que os desenvolvedores da agência podem continuar codificando nas linguagens e estruturas de aplicativos do Windows com as quais estão familiarizados.
A equipe de DevOps criou um conjunto principal de APIs REST para acessar os serviços de backend do .Net Core. As APIs são a cola que mantém unida a funcionalidade e a lógica do aplicativo e os microfront ends. Para o ambiente front-end, a equipe escolheu o AngularJS devido à sua ampla aceitação entre organizações governamentais como uma estrutura JavaScript robusta e confiável com uma comunidade forte.
Para criar uma camada de roteamento coesa para tráfego e chamadas de API entre os front-ends e back-ends, a equipe explorou várias opções antes de escolher o NGINX Open Source devido à sua versatilidade. As páginas no site da agência são criadas dinamicamente como microfront ends, extraindo elementos de conteúdo e usando a mesma lógica CSS para “skin” de vários serviços de back end. Para o usuário, parece que tudo está acontecendo dentro do mesmo aplicativo, "mas, na verdade, estamos usando proxy inteligente e reescritas com NGINX. Para preencher a tela com as informações apropriadas para o front-end, fazemos chamadas de API de back-end via NGINX", explica Benoit.
Para expor o aplicativo à Internet pública, Benoit implantou uma instância F5 NGINX Plus como um servidor web e proxy reverso em uma máquina virtual em execução na DMZ da agência. Ele explica por que o NGINX Plus é a opção certa: “Precisávamos do TLS 1.3 e queríamos agir rapidamente. Era acessível em comparação com aparelhos dedicados e poderíamos facilmente adicionar licenças”.
Benoit enfatiza que, para a agência, “o NGINX funciona como um servidor web, um proxy e um gateway de API básico para nossa camada de aplicação. É realmente um canivete suíço™ que pode fazer quase tudo. É por isso que o usamos.” Por exemplo, para recuperar um PDF carregado, os usuários selecionam o PDF necessário entre os documentos carregados em sua conta e o aplicativo de entrega de PDF envia uma solicitação ao serviço de recuperação de PDF de back-end anexado ao armazenamento de objetos do Ceph. O Ceph retorna a URL exclusiva do local do PDF no armazenamento de objetos, no qual o usuário clica para visualizar ou baixar.
Como o aplicativo é de missão crítica, a equipe projetou uma arquitetura de alta disponibilidade ativa-ativa com todos os aplicativos sendo executados em pelo menos dois clusters. Isso fornece redundância para todos os serviços, microfront ends e APIs, garantindo que eles continuem funcionando no caso de uma interrupção em um dos clusters.
Para melhorar o desempenho e habilitar um plano de controle para aplicativos compostos que abrangem vários serviços, a equipe usa o barramento de mensagens do AMQ Broker para configurar tópicos e filas para serviços. “Portanto, se algo pode ser executado em segundo plano, nós o fazemos em segundo plano”, diz Benoit. “Se uma mensagem chega e alguns dados do método precisam ser ajustados, temos ouvintes que podem processar algo ou encontrar os trabalhadores para executar o processo.” Para garantir um estado consistente para os usuários em todos os clusters, a equipe manteve sua infraestrutura de banco de dados Microsoft SQL Server de alta disponibilidade para manter o estado do pod e permitir a persistência da sessão.
Para observabilidade, Benoit recomendou o Grafana como painel nativo da nuvem. Para obter métricas do NGINX, a equipe de DevOps utiliza o NGINX Prometheus Exporter em um sidecar pareado a cada pod. O exportador extrai métricas da Camada 4 do módulo NGINX Open Source Stub Status e da API NGINX Plus , corresponde cada uma a uma string, cria um par chave-valor e envia o par para o Prometheus . A partir daí, o par é publicado em uma instância separada do Grafana, exposta apenas a desenvolvedores e equipes de DevOps. “É incrível. Posso criar painéis e coletar métricas em um único lugar em todas as minhas instâncias do NGINX Open Source e do NGINX Plus. A equipe de DevOps está no controle. Eles podem ver o que está acontecendo e receber alertas de problemas”, diz Benoit.
A equipe também usa as métricas para gerenciamento de desempenho do aplicativo. O Prometheus gera alertas para exceções e conexões não tratadas nos aplicativos, que sinalizam que não há trabalhadores suficientes em execução. Benoit vinculou as métricas ao recurso de dimensionamento automático no OpenShift. Ele explica: “Configurei a configuração do NGINX para um certo número de trabalhadores e calculei a RAM e a CPU necessárias. Se as coisas ficarem muito movimentadas em relação a essa linha de base, o OpenShift aumenta automaticamente e me envia um alerta.”
Quando um teste de penetração indicou que os aplicativos não usavam uma política de segurança de conteúdo (CSP) forte, a equipe conseguiu configurar o NGINX Open Source e o NGINX Plus com políticas para aplicação em linha do CSP. Eles também definiram configurações personalizadas para extrair informações de registro JSON da plataforma de contêiner e enviá-las para a plataforma de registro Splunk para análise histórica e manutenção de registros.
Para desenvolvedores front-end que usam o Google Analytics e o Lighthouse , o HCS tornou possível incluir verificações do Lighthouse no pipeline da agência, codificadas em configurações do NGINX. “Rapidamente percebemos que poderíamos obter ganhos significativos de desempenho mudando para a biblioteca de compressão GZIP”, diz Benoit, e o resultado é uma melhoria de 60% na latência do aplicativo.
Além disso, com a nova arquitetura, os desenvolvedores agora estão em contato direto com os usuários finais porque têm visibilidade detalhada do comportamento em tempo real. “O ciclo de feedback é muito mais rápido e, se algo acontecer e precisar ser alterado, podemos colocá-lo em produção em apenas um dia. Isso é muito rápido para governos, onde as mudanças costumavam levar meses ou até anos”, diz Benoit. “Para nossos desenvolvedores, isso é como a noite e o dia.”
Quer duplicar os excelentes resultados deste projeto construindo seu conjunto de tecnologia no NGINX Plus? Comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."