Compartilhar via

Refine sua plataforma de aplicativos

  • Artigo

Depois de começar a melhorar as práticas de engenharia de plataforma da sua organização, você pode descobrir que precisa enfrentar alguns desafios com sua plataforma de aplicativos primeiro. Sua plataforma de aplicativo inclui todos os recursos usados para alimentar um aplicativo, como um aplicativo criado diretamente no AKS (Serviço de Kubernetes do Azure).

Neste artigo, saiba mais sobre os aspectos frequentemente perdidos ou esquecidos da criação de uma plataforma de aplicativos bem arquitetada: gerenciamento de infraestrutura, governança, observabilidade e segurança.

  • Gerenciamento de infraestrutura: use a infraestrutura como código (IaC) e a automação, combinadas com modelos, para simplificar e padronizar a implantação de infraestrutura e aplicativos, além de fornecer mecanismos para gerenciamento de alterações e detecção de desvios de configuração.
  • Governança: use modelos de IaC para implementar estratégias de conformidade de implantação inicial e manutenção contínua, adicionar ferramentas baseadas em políticas e criar uma prática de política como código (PaC) para padrões centralizados.
  • Observabilidade: implemente observabilidade e registro em log específicos da função com painéis padronizados, garanta políticas de acesso e retenção apropriadas e monitore os limites de recursos e as principais métricas usando ferramentas como o Azure Policy.
  • Segurança: crie segurança em todas as camadas da plataforma de aplicativos com o princípio de privilégios mínimos, gerenciamento de segurança unificado em DevOps, detecção de ameaças e uso de ferramentas para lidar com vulnerabilidades e gerenciar a cadeia de suprimentos de software.
  • Gerenciamento de custos: gerencie os custos identificando proprietários de carga de trabalho e mapeando recursos, imponha propriedades obrigatórias para implantar recursos e atribuir custos a equipes, gerencie custos de recursos compartilhados e use ferramentas como o Gerenciamento de Custos da Microsoft para monitorar gastos e definir alertas.

Decidindo 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. Saiba mais sobre as abordagens de infraestrutura como código (IaC) e modelos já abordados em Aplicar sistemas de engenharia de software para ajudá-lo a gerenciar algumas dessas variações para novos aplicativos.
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.

Gerenciamento de infraestrutura

Conforme mencionado em Aplicar sistemas de engenharia de software, 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 no usuário final, você deve 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 (tamanho de camiseta, pequeno, médio e grande).

O objetivo deve ser ter modelos que representem 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 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 os serviços que você deseja oferecer ou para os quais deseja migrar. 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

Em sua organização, há muitos recursos que podem ser compartilhados por vários aplicativos para aumentar a utilização e a economia. Cada um dos recursos que podem ser compartilhados 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 organizacional, requisitos, prioridade, etc.
  • 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 devido ao esgotamento da capacidade. O uso de limites de recursos, testes representativos, alertas de monitoramento e relatórios pode ajudar a identificar o consumo de recursos e proteger contra aplicativos que consomem muitos recursos que podem afetar outros aplicativos.
  • 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.

Alguns desses problemas são simplificados pelas soluções PaaS, mas muitos desses pontos se aplicam até mesmo a algo como o compartilhamento de um banco de dados. O compartilhamento tem vantagens e desvantagens e, portanto, você deve considerar as compensações com cuidado.

Para obter mais informações sobre o aspecto de cluster do Kubernetes deste artigo, consulte a documentação de multilocação do AKS (Serviço de Kubernetes do Azure).

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. A governança é um tópico amplo, mas se esse é um problema que você está encontrando, lembre-se de ambos os aspectos deste espaço:

  • 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.

Observabilidade

Para dar suporte a seus aplicativos e infraestrutura, você precisa de observabilidade e registro em toda a pilha que suas equipes de engenharia, operações e desenvolvedores de plataforma podem usar para ver o que está acontecendo.

Ilustração de um painel do Grafana.

No entanto, 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: considere fornecer 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. Quando possível, 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.

Segurança

A segurança é necessária em todas as camadas, desde código, contêiner, cluster e nuvem/infraestrutura. Cada organização tem seus próprios requisitos de segurança, mas, em alto nível, estas são algumas coisas a serem consideradas para sua plataforma:

  • 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, você deseja avaliar:

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, em ambientes de desenvolvimento e teste, a implantação automatizada de recursos e aplicativos e o acesso a clusters para solução de problemas podem ser permitidos.

Gerenciar o acesso de identidade a serviços, aplicativos e infraestrutura em escala pode ser um desafio. Você deseja que os provedores de identidade criem, mantenham e gerenciem informações de identidade enquanto fornecem serviços de autenticação para aplicativos e serviços e que podem se integrar a sistemas de autorizações de controle de acesso baseados em função para autenticação em escala e gerenciamento de autorização (RBAC). Por exemplo, você pode usar o RBAC do Azure e 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.

Gerenciamento de custos

O custo é outro problema que pode chegar ao topo para seus esforços de 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 no rateio de custos, mapeamento de recursos da solução, proprietários, etc. 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é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 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.

Projetar uma base de autoatendimento para desenvolvedores