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

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

Simplificar e padronizar

A IaC (infraestrutura como código) e as ferramentas de automação podem ser combinadas com modelos para padronizar a infraestrutura e a implantação de aplicativos. Para reduzir a carga de detalhes da plataforma no usuário final, você pode abstrair 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 (por exemplo, tamanhos de camisetas P, M e G)

Os modelos devem representar requisitos gerais que foram testados com configurações predefinidas, portanto, as equipes de desenvolvimento podem começar imediatamente a fornecer parâmetros mínimos e sem a necessidade de examinar as opções. No entanto, há ocasiões em que as equipes precisam alterar mais opções em modelos publicados do que 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 com suporte. Nesse caso, as equipes de engenharia de plataforma ou operações podem criar uma configuração única e decidir se o modelo precisa incorporar essas alterações como padrão.

Você pode controlar as alterações usando ferramentas de IaC com recursos de detecção de descompasso que podem corrigir automaticamente o descompasso (GitOps). Exemplos dessas ferramentas são o Terraform e as ferramentas IaC nativas da nuvem (por exemplo, API de Cluster, Crossplane, Operador de Serviço do Azure v2). Fora da detecção de descompasso da ferramenta IaC, há ferramentas de configuração de nuvem que podem consultar configurações de recursos, como o Azure Resource Graph. Eles podem servir como dois benefícios; para monitorar alterações fora do código de infraestrutura e examinar 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 software como serviço (Saas), PaaS (plataforma como serviço) ou IaaS (infraestrutura como serviço). Para saber mais sobre SaaS, PaaS e IaaS, consulte o módulo de treinamento Descrever tipos de serviço 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 troca entre a facilidade de uso e o 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 dos Aplicativos de Contêiner do Azure depende de seus requisitos para o serviço e da capacidade interna e do conjunto de habilidades. O mesmo vale para serviços no estilo de função, como o Azure Functions ou o Serviço de Aplicativo do Azure. Aplicativos de Contêiner, Funções e Serviço de Aplicativo reduzem a complexidade, enquanto o AKS fornece mais flexibilidade e controle. Modelos de aplicativo mais experimentais, como o projeto de incubação radius oss , tentam fornecer um equilíbrio entre os dois, mas geralmente estão em estágios anteriores de maturidade do que os serviços de nuvem com suporte total e uma presença em formatos iac estabelecidos.

Os problemas que você identificou durante seu planejamento devem ajudá-lo a avaliar qual final dessa escala é ideal para você. Certifique-se de considerar seu próprio conjunto de habilidades interno existente ao tomar uma decisão.

Recursos compartilhados versus dedicados

Em sua organização, há recursos que podem ser compartilhados por vários aplicativos para aumentar a utilização e a eficácia do custo. Cada recurso compartilhado tem seu próprio conjunto de considerações. Por exemplo, essas são considerações para compartilhar clusters do Kubernetes, mas algumas se aplicam a outros tipos de recursos:

• Organização: O compartilhamento de recursos como clusters dentro, em vez de entre limites organizacionais, pode melhorar a forma como eles se alinham com a direção organizacional, os requisitos e a prioridade.
• Locação de aplicação: Os aplicativos podem ter diferentes requisitos de isolamento de locação; é necessário examinar a segurança e conformidade regulatória de aplicações individuais para determinar se podem 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 a combinação de 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 clusters do 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 e a capacidade de reposição de cada aplicativo 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 em site ativo quando a capacidade se esgotar. 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.
• Otimizar configurações compartilhadas: Recursos compartilhados, como clusters compartilhados, exigem consideração e configuração adicionais. 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 de carga de trabalho. Os recursos compartilhados têm benefícios, mas se as configurações padrão forem muito restritivas e não evoluirem, elas se tornarão obsoletas.

Implementar estratégias de governança

A governança é uma parte fundamental da habilitação do autoatendimento com diretrizes, mas aplicar regras de conformidade de maneira que não afete o tempo necessário para que os aplicativos gerem valor de negócio é um desafio comum. Há duas partes da governança:

• Conformidade inicial de implantação (comece à direita): Isso pode ser feito 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.
• Mantendo a conformidade (permaneça em conformidade): As ferramentas baseadas em políticas podem impedir ou alertar você quando houver alterações de recursos. Além da infraestrutura principal, considere que as ferramentas também dão suporte à conformidade dentro de recursos como o Kubernetes, juntamente com o sistema operacional usado 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 a repositórios iac, você poderá adicionar fluxos de trabalho de aprovação para examinar as alterações propostas e impedir o acesso direto a planos de controle de recursos, como o 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ório e correção. Ele também tem modos diferentes, como Audit, Deny e DeployIfNotExists , dependendo de suas necessidades.

Embora as políticas possam impor a conformidade, elas também podem interromper aplicativos inesperadamente. Portanto, considere a evolução para uma prática de PaC (política como código) ao operar em escala. Como uma parte fundamental da sua abordagem de começar bem e manter-se no caminho certo, o PaC fornece:

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

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

• Definições de política armazenadas como código em um repositório que é revisado e aprovado
• Automação para fornecer teste e validação
• A distribuição gradual baseada em anel de políticas e a correção em 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 a observabilidade e o registro em log específicos da função

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

Os requisitos diferem por função. Por exemplo, as equipes de engenharia e operações de plataforma exigem painéis para examinar a integridade e a capacidade da infraestrutura com alertas adequados. Os desenvolvedores exigem métricas de aplicativo, logs e rastreamentos 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 encontrar é a sobrecarga cognitiva de muita informação 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: Ofereça painéis de equipe ou de aplicativo usando algo como o Grafana para fornecer dados consolidados a qualquer pessoa interessada, além de um recurso para que membros confiáveis das equipes de aplicativos possam acessar com segurança os 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 de dados e publique-os como parte das orientações para início correto.
• Monitorar 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 fatoradas em modelos ou políticas de IaC usando ferramentas como o Azure Policy. Em seguida, as operações devem monitorar proativamente o uso de dashboards em algo como o Grafana e expandir os recursos compartilhados em que o dimensionamento automatizado não é possível ou habilitado. Por exemplo, monitore o número de nós de cluster do Kubernetes para capacidade, pois os aplicativos são integrados e modificados ao longo do tempo. O alerta é necessário 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 saúde: Monitore e alerte sobre o sistema operacional e os recursos compartilhados (por exemplo, CPU, memória e armazenamento) em caso de escassez, coletando métricas usando ferramentas como Prometheus ou monitoramento de Kubernetes no Azure Monitor. Você pode monitorar soquetes/portas em uso, o consumo de largura de banda de rede de aplicativos verbosos e o número de aplicativos com estado hospedados no cluster.

Incorporar segurança com o princípio do menor privilégio, gerenciamento unificado de segurança 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 do privilégio mínimo.
• Unifique o gerenciamento de segurança do DevOps em vários pipelines.
• Verifique se os insights contextuais para identificar e corrigir o risco mais crítico estão visíveis.
• Habilite a detecção e a resposta a ameaças modernas em suas cargas de trabalho de nuvem em runtime.

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

• Gerenciamento de superfície de ataque externo usando algo como o Gerenciamento de Superfície de Ataque Externo do Microsoft Defender (Defender EASM).
• Serviços de segurança de rede – proteja aplicativos e cargas de trabalho de nuvem contra ataques cibernéticos baseados em rede usando algo como a Segurança de Rede do Azure.
• Análise de segurança inteligente usando uma solução de SIEM (gerenciamento de eventos e informações de segurança), como o Microsoft Sentinel.
• Maneiras de governar, proteger, visualizar e gerenciar seu patrimônio de dados com segurança, como o Microsoft Purview.
• Maneiras de verificar o código em busca de possíveis vulnerabilidades de segurança, detectar segredos, examinar dependências como a Segurança Avançada do GitHub e a Segurança Avançada do GitHub para Azure DevOps.
• Gerenciamento da cadeia de fornecimento de software, especialmente para contêineres. Por exemplo, aplique o Containers Secure Supply Chain Framework.

Os requisitos de permissões podem ser diferentes por 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, infraestrutura em escala pode ser desafiador. Os provedores de identidade criam, mantêm e gerenciam informações de identidade. Seu plano deve incluir serviços de autenticação para aplicativos e serviços, e esse serviço deve se integrar aos sistemas de autorizações de RBAC (controle de acesso baseado 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 examinar os requisitos e avaliar como seu provedor de identidade pode dar suporte a isso da maneira mais segura possível. Por exemplo, no Serviço de Kubernetes do Azure, os aplicativos nativos de nuvem podem utilizar uma identidade de carga de trabalho federada com a ID do Microsoft Entra para permitir que cargas de trabalho em contêineres se autentiquem. Essa abordagem permite que os aplicativos acessem recursos de nuvem sem trocas secretas no código do aplicativo.

Reduzir custos identificando proprietários de carga de trabalho e rastreando recursos

O gerenciamento de custos é outra parte da engenharia de plataforma. Para gerenciar corretamente 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 associa recursos a seus respectivos proprietários com base em um conjunto específico de metadados. Por exemplo, no Azure, você pode usar Rótulos AKS, tags do Azure Resource Manager, junto com conceitos de 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 o 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 acompanhamento, talvez seja necessário atribuir custo a equipes de aplicativos individuais para o uso de recursos usando esses mesmos metadados com sistemas de gerenciamento de custos, como o Gerenciamento de Custos da Microsoft. Embora esse método acompanhe os recursos provisionados pelas equipes de aplicativos, ele não cobre o custo de recursos compartilhados, como seu provedor de identidade, registro em log e armazenamento de métricas 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 em log) em que há consumo nãouniforme. Alguns tipos de recursos compartilhados podem ser capazes de 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 em que possa examinar os gastos atuais. Por exemplo, no portal do Azure, há alertas de custo e orçamentos que podem acompanhar o consumo de recursos em um grupo e enviar notificações quando você atinge os limites predefinidos.

Decidir quando e onde investir

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

Adaptar os investimentos em sua plataforma de aplicativos existente pode ser uma boa maneira de começar. Ao fazer atualizações, considere começar com novos aplicativos para simplificar ideias piloto antes de qualquer tipo de distribuição. Incorpore essa alteração por meio de Infraestrutura como Código (IaC) e modelagem de aplicativos. 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 fora da prateleira. Assim como acontece com os sistemas de engenharia, concentre-se em automatizar o provisionamento, o acompanhamento e a implantação, em vez de assumir um caminho rígido para ajudá-lo a gerenciar as alterações ao longo do tempo.

Conteúdo relacionado

• Criar uma base de autoatendimento do desenvolvedor