Compartilhar via

Refine sua plataforma de aplicativos para simplificar o desenvolvimento de aplicativos e o gerenciamento de infraestrutura

  • Artigo

Uma grande parte da melhoria das práticas de engenharia de plataforma da sua organização é avaliar sua plataforma de aplicativos. Uma plataforma de aplicativos inclui todas as ferramentas e serviços usados para dar suporte ao desenvolvimento, implantação e gerenciamento de aplicativos em sua organização.

Simplifique e padronize

As ferramentas de infraestrutura como código (IaC) e automação podem ser combinadas com modelos para padronizar a implantação de infraestrutura e aplicativos. Para reduzir a carga de especificidades da plataforma no usuário final, abstraia os detalhes da plataforma dividindo as opções em convenções de nomenclatura relacionáveis, por exemplo:

  • Categorias de tipo de recurso (computação alta, memória alta)
  • Categorias de tamanho de recurso (tamanho de camiseta, pequeno, médio e grande)

Os modelos devem representar requisitos gerais que foram testados com configurações predefinidas, para que as equipes de desenvolvimento possam começar imediatamente a fornecer parâmetros mínimos e sem precisar revisar as opções. No entanto, haverá ocasiões em que as equipes precisarão alterar mais opções nos modelos publicados do que as disponíveis ou desejáveis. Por exemplo, um design aprovado pode precisar de uma configuração específica que esteja fora dos padrões de modelo suportados. Nesse caso, as equipes de engenharia de operações ou plataforma podem criar uma configuração única e, em seguida, decidir se o modelo precisa incorporar essas alterações como padrão.

Você pode acompanhar as alterações usando ferramentas de IaC com recursos de detecção de desvio que podem corrigir automaticamente o desvio (GitOps). Exemplos dessas ferramentas são Terraform e ferramentas de IaC nativas de nuvem (exemplos, API de cluster, Crossplane, Azure Service Operator v2). Fora da detecção de desvio de ferramentas de IaC, há ferramentas de configuração de nuvem que podem consultar configurações de recursos, como o Azure Resource Graph. Estes podem servir como dois benefícios; Você monitora as alterações fora do código de infraestrutura e analisa as configurações predefinidas alteradas. Para evitar ser muito rígido, você também pode implementar tolerâncias em implantações com limites predefinidos. Por exemplo, você pode usar o Azure Policy para limitar o número de nós do Kubernetes que uma implantação pode ter.

Autogerenciado ou gerenciado?

Em nuvens públicas, você tem a opção de consumir SaaS, PaaS ou IaaS. Para saber mais sobre SaaS, PaaS e IaaS, consulte o módulo de treinamento Descrever conceitos de nuvem. Os serviços de PaaS oferecem experiências de desenvolvimento simplificadas, mas são mais prescritivos com seus modelos de aplicativo. Em última análise, há uma compensação entre facilidade de uso e controle que você precisa avaliar.

Durante o design da plataforma, avalie e priorize as necessidades de serviço da sua organização. Por exemplo, se você cria aplicativos diretamente no AKS (Serviço de Kubernetes do Azure) ou por meio do ACA (Aplicativos de Contêiner do Azure) depende de seus requisitos para o serviço e de sua capacidade interna e conjunto de habilidades. O mesmo vale para serviços de estilo de função, como Azure Functions ou Serviço de Aplicativo do Azure. O ACA, o Azure Functions e o Serviço de Aplicativo reduzem a complexidade, enquanto o AKS fornece mais flexibilidade e controle. Modelos de aplicativos mais experimentais, como o projeto de incubação OSS Radius , tentam fornecer um equilíbrio entre os dois, mas geralmente estão em estágios iniciais de maturidade do que os serviços em nuvem com suporte total e presença em formatos IaC estabelecidos.

Os problemas que você identificou quando planejou devem ajudá-lo a avaliar qual extremidade dessa escala é a certa para você. Certifique-se de levar em consideração seu próprio conjunto de habilidades internas existentes ao tomar uma decisão.

Recursos compartilhados vs. dedicados

Dentro de sua organização, há recursos que podem ser compartilhados por vários aplicativos para aumentar a utilização e a economia. Cada recurso compartilhado tem seu próprio conjunto de considerações. Por exemplo, estas são considerações para compartilhar clusters K8s, mas algumas se aplicarão a outros tipos de recursos:

  • Organização: compartilhar recursos como clusters dentro, em vez de cruzar, os limites organizacionais pode melhorar a forma como eles se alinham com a direção, os requisitos e a prioridade da organização.
  • Locação de aplicativos: os aplicativos podem ter diferentes requisitos de isolamento de locação; você precisa revisar a segurança de aplicativos individuais e a conformidade regulatória se eles puderem coexistir com outros aplicativos. Por exemplo, no Kubernetes, os aplicativos podem usar o isolamento de namespace. Mas você também deve considerar a locação de aplicativos para diferentes tipos de ambiente. Por exemplo, geralmente é melhor evitar misturar aplicativos de teste com aplicativos de produção nos mesmos clusters para evitar impactos inesperados devido a configurações incorretas ou problemas de segurança. Ou você pode optar por primeiro testar e ajustar em clusters Kubernetes dedicados para rastrear esses problemas antes da implantação em um cluster compartilhado. Independentemente disso, a consistência em sua abordagem é a chave para evitar confusão e erros.
  • Consumo de recursos: entenda o uso de recursos de cada aplicativo, a capacidade sobressalente e faça uma projeção para estimar se o compartilhamento é viável. Você também deve estar ciente dos limites dos recursos consumidos (capacidade do data center ou limites de assinatura). O objetivo é evitar mover seu aplicativo e dependências devido a restrições de recursos em um ambiente compartilhado ou ter incidentes de site ativo quando a capacidade acabar. Use limites de recursos, testes representativos, alertas de monitoramento e relatórios para identificar o consumo de recursos e proteger contra aplicativos que consomem muitos recursos.
  • Otimize as configurações compartilhadas: recursos compartilhados, como clusters compartilhados, exigem consideração e configuração extras. Essas considerações incluem cobrança cruzada, alocação de recursos, gerenciamento de permissões, propriedade da carga de trabalho, compartilhamento de dados, coordenação de atualização, posicionamento da carga de trabalho, estabelecimento, gerenciamento e iteração de uma configuração de linha de base, gerenciamento de capacidade e posicionamento da carga de trabalho. Os recursos compartilhados têm benefícios, mas se as configurações padrão forem muito restritivas e não evoluírem, elas se tornarão obsoletas.

Implementar estratégias de governança

A governança é uma parte fundamental da habilitação do autoatendimento com proteções, mas aplicar regras de conformidade de uma forma que não afete o tempo de valor comercial dos aplicativos é um desafio comum. Existem duas partes da governança:

  • Conformidade de implantação inicial (início à direita): isso pode ser obtido com modelos de IaC padronizados que são disponibilizados por meio de catálogos, com gerenciamento de permissões e políticas para garantir que apenas recursos e configurações permitidos possam ser implantados.
  • Manter a conformidade (fique à direita): as ferramentas baseadas em políticas podem impedir ou alertá-lo quando houver alterações de recursos. Além de sua infraestrutura principal, considere que as ferramentas também dão suporte à conformidade dentro de recursos como K8s, juntamente com sistemas operacionais usados em seus contêineres ou VMs. Por exemplo, talvez você queira impor uma configuração de sistema operacional bloqueada ou instalar ferramentas de software de segurança, como Política de Grupo do Windows, SELinux, AppArmor, Azure Policy ou Kyverno. Se os desenvolvedores tiverem acesso apenas aos repositórios de IaC, você poderá adicionar fluxos de trabalho de aprovação para examinar as alterações propostas e impedir o acesso direto aos planos de controle de recursos (por exemplo, Azure).

Manter a conformidade requer ferramentas para acessar, relatar e agir sobre problemas. Por exemplo, o Azure Policy pode ser usado com muitos serviços do Azure para auditoria, relatórios e correção. Ele também tem modos diferentes, como Auditar, Negar e DeployIfNotExists, dependendo de suas necessidades.

Embora as políticas possam impor a conformidade, elas também podem interromper os aplicativos inesperadamente. Portanto, considere evoluir para uma prática de política como código (PaC) ao operar em escala. Como parte fundamental de sua abordagem de começar certo e permanecer certo , o PaC oferece:

  • Padrões gerenciados centralmente
  • Controle de versão para suas políticas
  • Teste e validação automatizados
  • Tempo reduzido para implantação
  • Implantação contínua

O PaC pode ajudar a minimizar o raio de explosão de uma política potencialmente ruim com recursos como:

  • Definições de política armazenadas como código em um repositório que é revisado e aprovado.
  • Automação para fornecer testes e validação.
  • A implementação gradual de políticas baseada em anel e a correção nos recursos existentes ajudam a minimizar o raio de explosão de uma política potencialmente ruim.
  • A tarefa de correção tem segurança interna, com controles como interromper a tarefa de correção se mais de 90% das implantações falharem.

Implementar observabilidade e registro em log específicos da função

Para dar suporte a seus aplicativos e infraestrutura, você precisa de observabilidade e registro em toda a sua pilha.

Ilustração de um painel do Grafana mostrando observabilidade e registro em log.

Os requisitos diferem por função. Por exemplo, a equipe de engenharia e operações da plataforma exige painéis para revisar a integridade e a capacidade da infraestrutura com alertas adequados. Os desenvolvedores precisam de métricas, logs e rastreamentos de aplicativos para solucionar problemas e painéis personalizados que mostram a integridade do aplicativo e da infraestrutura. Um problema que qualquer uma dessas funções pode estar encontrando é a sobrecarga cognitiva de muitas informações ou lacunas de conhecimento devido à falta de informações úteis.

Para resolver esses desafios, considere o seguinte:

  • Padrões: aplique padrões de registro em log para facilitar a criação e a reutilização de painéis padronizados e simplificar o processamento de ingestão por meio de algo como a estrutura de observabilidade do OpenTelemetry.
  • Permissões: forneça painéis no nível da equipe ou do aplicativo usando algo como o Grafana para fornecer dados acumulados para qualquer pessoa interessada, juntamente com um recurso para que membros confiáveis das equipes de aplicativos obtenham acesso seguro aos logs quando necessário.
  • Retenção: a retenção de logs e métricas pode ser cara e pode criar riscos não intencionais ou violações de conformidade. Estabeleça padrões de retenção e publique-os como parte de suas diretrizes para começar certo.
  • Monitore os limites de recursos: as equipes de operações devem ser capazes de identificar e rastrear quaisquer limitações para um determinado tipo de recurso. Essas limitações devem ser levadas em consideração em modelos ou políticas de IaC usando ferramentas como Azure Policy. As operações devem monitorar proativamente o uso de painéis em algo como o Grafana e expandir os recursos compartilhados onde o dimensionamento automatizado não é possível ou habilitado. Por exemplo, monitore o número de nós de cluster K8s para capacidade à medida que os aplicativos são integrados e modificados ao longo do tempo. Os alertas são necessários e essas definições devem ser armazenadas como código para que possam ser adicionadas programaticamente aos recursos.
  • Identifique as principais métricas de capacidade e integridade: monitore e alerte o sistema operacional e os recursos compartilhados (exemplos: CPU, memória, armazenamento) para privação com a coleta de métricas usando algo como Prometheus ou Azure Container Insights. Você pode monitorar soquetes/portas em uso, consumo de largura de banda de rede de aplicativos tagarelas e o número de aplicativos com estado hospedados no cluster.

Crie segurança com o princípio de privilégios mínimos, gerenciamento de segurança unificado e detecção de ameaças

A segurança é necessária em todas as camadas, desde código, contêiner, cluster e nuvem/infraestrutura. Estas são as etapas mínimas de segurança recomendadas:

  • Siga o princípio dos privilégios mínimos.
  • Unifique seu gerenciamento de segurança de DevOps em vários pipelines.
  • Certifique-se de que os insights contextuais para identificar e corrigir seu risco mais crítico estejam visíveis.
  • Habilite a detecção e a resposta a ameaças modernas em suas cargas de trabalho de nuvem em tempo de execução.

Para ajudar a resolver problemas nessa área, você precisa de ferramentas para avaliar ferramentas que funcionam em seus sistemas de engenharia e aplicativos, recursos e serviços em nuvens e híbridas (por exemplo, Microsoft Defender para Nuvem). Além da segurança do aplicativo, avalie:

Os requisitos de permissões podem variar de acordo com o ambiente. Por exemplo, em algumas organizações, equipes individuais não têm permissão para acessar recursos de produção e novos aplicativos não podem ser implantados automaticamente até que as revisões sejam concluídas. No entanto, a implantação automatizada de recursos e aplicativos e o acesso a clusters para solução de problemas podem ser permitidos em ambientes de desenvolvimento e teste.

Gerenciar o acesso de identidade a serviços, aplicativos e infraestrutura em escala pode ser um desafio. Provedores de identidade para criar, manter e gerenciar informações de identidade. Seu plano deve incluir serviços de autenticação para aplicativos e serviços e que podem se integrar a sistemas RBAC (autorizações de controle de acesso baseadas em função) em escala. Por exemplo, você pode usar a ID do Microsoft Entra para fornecer autenticação e autorização em escala para serviços do Azure, como o Serviço de Kubernetes do Azure, sem precisar configurar permissões diretamente em cada cluster individual.

Os aplicativos podem precisar de acesso a uma identidade para acessar recursos de nuvem, como armazenamento. Você precisa revisar os requisitos e avaliar como seu provedor de identidade pode oferecer suporte a isso da maneira mais segura possível. Por exemplo, no AKS, os aplicativos nativos de nuvem podem utilizar uma identidade de carga de trabalho que se federa com a ID do Microsoft Entra para permitir que cargas de trabalho em contêineres sejam autenticadas. Essa abordagem permite que os aplicativos acessem recursos de nuvem sem trocas secretas no código do aplicativo.

Reduza os custos identificando os proprietários da carga de trabalho e rastreando recursos

Gerenciar custos é outra parte da engenharia de plataforma. Para gerenciar adequadamente sua plataforma de aplicativos, você precisa de uma maneira de identificar os proprietários da carga de trabalho. Você deseja uma maneira de obter um inventário de recursos que mapeia para os proprietários de um determinado conjunto de metadados. Por exemplo, no Azure, você pode usar rótulos do AKS, marcas do Azure Resource Manager, juntamente com conceitos como projetos em ambientes de implantação do Azure para agrupar seus recursos em diferentes níveis. Para que isso funcione, os metadados escolhidos devem incluir propriedades obrigatórias (usando algo como Azure Policy) ao implantar cargas de trabalho e recursos. Isso ajuda na alocação de custos, no mapeamento de recursos da solução e nos proprietários. Considere executar relatórios regulares para rastrear recursos órfãos.

Além do rastreamento, talvez seja necessário atribuir custos a equipes de aplicativos individuais pelo uso de recursos usando esses mesmos metadados com sistemas de gerenciamento de custos, como o Gerenciamento de Custos da Microsoft. Embora esse método rastreie os recursos provisionados pelas equipes de aplicativos, ele não cobre o custo de recursos compartilhados, como seu provedor de identidade, armazenamento de log e métrica e consumo de largura de banda de rede. Para recursos compartilhados, você pode dividir igualmente os custos operacionais pelas equipes individuais ou fornecer sistemas dedicados (por exemplo, armazenamento de log) onde há consumo não uniforme. Alguns tipos de recursos compartilhados podem fornecer insights sobre o consumo de recursos, por exemplo, o Kubernetes tem ferramentas como OpenCost ou Kubecost e pode ajudar.

Você também deve procurar ferramentas de análise de custos onde possa revisar os gastos atuais. Por exemplo, no portal do Azure, há alertas de custo e alertas de orçamentos que podem acompanhar o consumo de recursos em um grupo e enviar notificações quando você atinge limites predefinidos.

Decida quando e onde investir

Se você tiver mais de uma plataforma de aplicativos, pode ser complicado decidir quando e onde investir em melhorias que resolvam problemas como altos custos ou baixa observabilidade. Se você estiver começando do zero, o Centro de Arquitetura do Azure tem vários padrões potenciais para você avaliar. Mas, além disso, aqui estão algumas perguntas a serem consideradas ao começar a planejar o que deseja fazer:

Pergunta Dicas
Deseja adaptar sua plataforma de aplicativos existente, começar do zero ou usar uma combinação dessas abordagens? Mesmo que você esteja feliz com o que tem agora ou esteja começando do zero, você quer pensar em como se adaptar às mudanças ao longo do tempo. Mudanças imediatas raramente funcionam. Suas plataformas de aplicativos são um alvo em movimento. Seu sistema ideal muda com o passar do tempo. Você deseja levar em consideração esse pensamento e quaisquer planos de migração relacionados em seu design avançado.
Se você deseja mudar o que está fazendo hoje, com quais produtos, serviços ou investimentos está satisfeito? Como diz o ditado, "se não está quebrado, não conserte". Não mude as coisas sem uma razão para fazê-lo. No entanto, se você tiver alguma solução caseira, considere se é hora de mudar para um produto existente para economizar na manutenção a longo prazo. Por exemplo, se você estiver operando sua própria solução de monitoramento, deseja remover essa carga de sua equipe de operações e migrar para um novo produto gerenciado?
Onde você vê mais mudanças acontecendo ao longo do tempo? Algum deles está em áreas comuns a todos (ou à maioria) dos tipos de aplicativos da sua organização? Áreas com as quais você ou seus clientes internos não estão satisfeitos e provavelmente não mudarão com frequência são ótimos lugares para começar. Estes têm o maior retorno sobre o investimento a longo prazo. Isso também pode ajudá-lo a descobrir como você ajudaria a facilitar a migração para uma nova solução. Por exemplo, os modelos de aplicativo tendem a ser fluidos, mas as ferramentas de análise de log tendem a ter uma vida útil mais longa. Você também pode se concentrar em novos projetos / aplicativos para iniciar enquanto confirma que a mudança de direção tem os retornos desejados.
Você está investindo em soluções personalizadas em áreas com maior valor agregado? Você acha que um recurso exclusivo de plataforma de infraestrutura de aplicativos faz parte de sua vantagem competitiva? Se você identificou lacunas, antes de fazer algo personalizado, considere em quais áreas os fornecedores têm maior probabilidade de investir e concentre seu pensamento personalizado em outro lugar. Comece pensando em si mesmo como um integrador, em vez de uma infraestrutura de aplicativo personalizada ou provedor de modelo de aplicativo. Qualquer coisa que você construir terá que ser mantida, o que supera os custos iniciais a longo prazo. Se você sentir a necessidade urgente de criar uma solução personalizada em uma área que suspeita que será coberta por fornecedores a longo prazo, planeje o fim ou o suporte de longo prazo. Seus clientes internos normalmente ficarão tão satisfeitos (se não mais) com um produto pronto para uso quanto com um personalizado.

Adaptar seus investimentos existentes na plataforma de aplicativos pode ser uma boa maneira de começar. Ao fazer atualizações, considere começar com novos aplicativos para simplificar as ideias de piloto antes de qualquer tipo de distribuição. Considere essa alteração por meio de IaC e modelos de aplicativo. Invista em soluções personalizadas para suas necessidades exclusivas em áreas de alto impacto e alto valor. Caso contrário, tente usar uma solução pronta para uso. Assim como acontece com os sistemas de engenharia, concentre-se em automatizar o provisionamento, o rastreamento e a implantação, em vez de assumir um caminho rígido para ajudá-lo a gerenciar as mudanças ao longo do tempo.

Conteúdo relacionado

Projetar uma base de autoatendimento para desenvolvedores