Refine 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 a sua plataforma de aplicação. 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

Infraestrutura como código (IaC) e ferramentas de automação podem ser combinadas com modelos para padronizar a infraestrutura e a implantação de aplicativos. Para reduzir a carga de especificidades da plataforma para o 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, tamanho de camisetas em 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 a necessidade de revisar opções. No entanto, há ocasiões em que as equipes precisam alterar mais opções em modelos publicados do que estão 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 controlar alterações usando ferramentas IaC com recursos de deteção de desvio que podem corrigir automaticamente o desvio (GitOps). Exemplos dessas ferramentas são Terraform e ferramentas IaC nativas da nuvem (por exemplo, API de Cluster, Crossplane, Operador de Serviço do Azure v2). Fora da deteção de desvio da ferramenta 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; para monitorar alterações fora do código de infraestrutura e para revisar 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 a Política do Azure para limitar o número de nós do Kubernetes que uma implantação pode ter.

Autogerido ou gerido?

Nas nuvens públicas, você tem a opção de consumir software como serviço (Saas), plataforma como serviço (PaaS) ou infraestrutura como serviço (IaaS). 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. No final das contas, há um compromisso entre facilidade de uso e controlo que precisas avaliar.

Durante o projeto da plataforma, avalie e priorize as necessidades de serviço da sua organização. Por exemplo, se você cria aplicativos diretamente no Serviço Kubernetes do Azure (AKS) ou por meio de 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 o Azure Functions ou o Serviço de Aplicativo do Azure. Os Aplicativos de Contêiner, Funções e Serviço de Aplicativo reduzem a complexidade, enquanto o AKS oferece mais flexibilidade e controle. Modelos de aplicativos 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 iniciais de maturidade do que os serviços em nuvem com suporte total e presença em formatos IaC estabelecidos.

Os problemas identificados durante o seu planeamento devem ajudá-lo a avaliar qual o fim desta escala mais adequado para si. Certifique-se de considerar seu próprio conjunto de habilidades internas existentes ao tomar uma decisão.

Recursos partilhados versus recursos dedicados

Dentro da sua organização, há recursos que podem ser compartilhados por vários aplicativos para aumentar a utilização e a relação custo-benefício. Cada recurso partilhado tem o 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 dos limites organizacionais, em vez de cruzá-los, pode melhorar a forma como eles se alinham com a direção, os requisitos e a prioridade organizacionais.
• Tenência de aplicações: As aplicações podem ter diferentes requisitos de isolamento de tenência; deve-se revisar a segurança de aplicações individuais e a conformidade regulatória caso possam coexistir com outras aplicações. 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 clusters Kubernetes dedicados para rastrear esses problemas antes da implantação em um cluster compartilhado. Independentemente disso, a consistência na sua abordagem é a chave para evitar confusões e erros.
• Consumo de recursos: Entenda o uso de recursos e a capacidade ociosa 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 a transferência de seu aplicativo e dependências devido a restrições de recursos em um ambiente compartilhado, ou ter incidentes no site em tempo real quando a capacidade se esgotar. Use limites de recursos, testes representativos, alertas de monitorização e relatórios para identificar o consumo de recursos e proteger contra aplicativos que consomem excesso de recursos.
• Otimize as configurações compartilhadas: Recursos compartilhados, como clusters compartilhados, exigem consideração e configuração extras. Essas considerações incluem carregamento cruzado, 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 para permitir o autoatendimento com linhas de proteção, mas aplicar as regras de conformidade de uma forma que não afete o tempo para alcançar valor para o negócio dos aplicativos é um desafio comum. Existem duas partes da governação:

• Conformidade inicial da implantação (começar à direita): Isso pode ser alcançado com modelos 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 (mantenha-se correto): As ferramentas baseadas em políticas podem impedir ou alertá-lo quando houver alterações de recursos. Além da sua infraestrutura principal, considere que as ferramentas também oferecem 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, Política do Azure ou Kyverno. Se os desenvolvedores só tiverem acesso aos repositórios IaC, você poderá adicionar fluxos de trabalho de aprovação para revisar 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 os problemas. Por exemplo, a Política do Azure pode ser usada com muitos serviços do Azure para auditoria, relatórios e correção. Ele também tem diferentes modos, como Audit, Deny e DeployIfNotExists, conforme as suas necessidades.

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

• Normas geridas centralmente
• Controle de versão para suas políticas
• Testes e validação automatizados
• Tempo reduzido de implementação
• Desdobramento contínuo

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 revisado e aprovado
• Automação para fornecer testes e validação
• A implantação gradual de políticas com base em anéis e a correção em recursos existentes ajudam a minimizar o impacto de potencialmente uma política defeituosa.
• A tarefa de remediação tem segurança integrada, com controles como a interrupção da tarefa de remediaçã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 log em toda a pilha.

Os requisitos variam de função para função. Por exemplo, as equipes de engenharia e operações da plataforma exigem painéis para analisar 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 mostrem a integridade do aplicativo e da infraestrutura. Um problema que qualquer um desses papéis 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:

• Normas: Aplique padrões de registro para facilitar a criação e reutilização de painéis padronizados e simplifique o processamento de ingestão por meio de algo como a estrutura de observabilidade OpenTelemetria.
• Permissões: Forneça painéis de equipe ou de nível de aplicativo usando algo como o Grafana para fornecer dados acumulados para qualquer pessoa interessada, juntamente com um recurso para membros confiáveis de equipes de aplicativos obterem acesso seguro aos logs quando necessário.
• Retenção: A retenção de logs e métricas pode ser cara e criar riscos não intencionais ou violações de conformidade. Estabeleça padrões de retenção e publique-os como parte de sua orientação inicial correta.
• Monitore os limites de recursos: As equipas de operações devem ser capazes de identificar e controlar quaisquer limitações para um determinado tipo de recurso. Essas limitações devem ser consideradas em modelos ou políticas do IaC usando ferramentas como a Política do Azure. As operações devem, então, 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 do Kubernetes quanto à capacidade à medida que os aplicativos são integrados e modificados ao longo do tempo. Alertas são necessários, e essas definições devem ser armazenadas como código para que possam ser programaticamente adicionadas aos recursos.
• Identifique as principais métricas de capacidade e integridade: Monitore e alerte o sistema operacional e os recursos compartilhados (por exemplo, CPU, memória e armazenamento) em caso de esgotamento, com a recolha de métricas usando algo como o Prometheus ou o monitoramento do Kubernetes no Azure Monitor. Você pode monitorizar sockets/portas em uso, o consumo de largura de banda de rede de aplicações que consomem muita largura de banda, e o número de aplicações com estado hospedadas no cluster.

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

A segurança é necessária em todas as camadas, desde código, contêiner, cluster e nuvem/infraestrutura. Estes são os passos mínimos de segurança recomendados:

• Siga o princípio do menor privilégio.
• Unifique seu gerenciamento de segurança de DevOps em vários pipelines.
• Certifique-se de que insights contextuais para identificar e remediar seu risco mais crítico sejam visíveis.
• Habilite a deteção e a resposta a ameaças modernas em suas cargas de trabalho na 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, recursos e serviços de engenharia e aplicativos em nuvens e híbridos (por exemplo, Microsoft Defender for Cloud). Além da segurança do aplicativo, avalie:

• Gestão de superfície de ataque externo usando algo como Microsoft Defender External Attack Surface Management (Defender EASM).
• Serviços de segurança de rede - Proteja aplicativos e cargas de trabalho na nuvem contra ataques cibernéticos baseados em rede usando algo como o Azure Network Security.
• Análise de segurança inteligente usando uma solução de gerenciamento de eventos e informações de segurança (SIEM) 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, detetar segredos, revisar dependências como o GitHub Advanced Security e o GitHub Advanced Security for Azure DevOps.
• Gestão da sua cadeia de fornecimento de software, particularmente para contentores de software. Por exemplo, aplique o Containers Secure Supply Chain Framework.

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. 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 esses serviços devem se integrar a sistemas de autorizações 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 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, dentro do Serviço Kubernetes do Azure, os aplicativos nativos da 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 dentro do código do aplicativo.

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

A gestão de custos é outra parte da engenharia da plataforma. Para gerenciar adequadamente sua plataforma de aplicativos, você precisa de uma maneira de identificar os proprietários da carga de trabalho. Você quer uma maneira de obter um inventário de recursos que atribui aos proprietários para um conjunto específico de metadados. Por exemplo, no Azure, você pode usar AKS Labels, tags 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 a Política do Azure) 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 para o uso de recursos usando esses mesmos metadados com sistemas de gerenciamento de custos como o Microsoft Cost Management. 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, registro em log e armazenamento métrico e consumo de largura de banda de rede. Para recursos compartilhados, você pode igualmente dividir os custos operacionais pelas equipes individuais ou fornecer sistemas dedicados (por exemplo, armazenamento em log) onde há consumo não uniforme. Alguns tipos de recursos compartilhados podem fornecer informações 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 você pode rever os gastos atuais. Por exemplo, no portal do Azure, há alertas de custos e alertas de orçamentos que podem controlar 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, a Central de Arquitetura do Azure tem vários padrões potenciais para você avaliar. Mas, além disso, aqui estão algumas perguntas a considerar quando você começa a planejar o que deseja fazer:

Adaptar seus investimentos em plataformas de aplicativos existentes pode ser uma boa maneira de começar. Ao fazer atualizações, considere começar com novos aplicativos para simplificar as ideias-piloto antes de qualquer tipo de implantação. Considere essa alteração por meio do IaC e da criação de modelos 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 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 autosserviço para desenvolvedores