Share via

Refinar sua plataforma de aplicativo

  • Artigo

Depois de entender os problemas que deseja enfrentar primeiro em sua jornada de engenharia de plataforma, talvez você descubra que precisa enfrentar alguns desafios com sua plataforma de aplicativos. Este artigo fornece algumas dicas de como você pode fazer exatamente isso. Você aprenderá mais sobre os aspectos muitas vezes perdidos ou esquecidos da criação de uma plataforma de aplicativo bem arquiteta. Especificamente, gerenciamento de infraestrutura, segurança, gerenciamento de custos, governança e observabilidade.

Decidir quando e onde investir

Se você tem uma ou mais plataformas de aplicativo hoje, pode ser complicado decidir quando e onde investir em melhorias que resolvam os problemas identificados. 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:

Pergunta Dicas
Deseja adaptar sua plataforma de aplicativo existente, começar de novo ou usar uma combinação dessas abordagens? Mesmo que você esteja feliz com o que tem agora ou está começando de novo, você vai querer pensar em como se adaptar às mudanças ao longo do tempo. O corte relâmpago raramente funciona. Independentemente disso, assim como os sistemas de engenharia, suas plataformas de aplicativos são um destino móvel. O que você pousar hoje mudará com o passar do tempo. Você desejará considerar esse pensamento e quaisquer planos de migração relacionados ao seu design de avanço. Saiba mais sobre iac (infraestrutura como código) já coberta e abordagens de modelagem em Aplicar sistemas de engenharia de software para ajudá-lo a gerenciar parte dessa variação para novos aplicativos.
Se você quer mudar o que está fazendo hoje, com quais produtos, serviços ou investimentos você está satisfeito? Como diz o ditado, "se não estiver quebrado, não conserte." Não mude as coisas sem uma razão para fazê-lo. No entanto, se você tiver soluções domésticas, considere se é hora de ir em direção a um produto existente para economizar na manutenção de 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ê a maior mudança acontecendo ao longo do tempo? Alguma dessas áreas é comum a todos (ou à maioria) dos tipos de aplicativo 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 no 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 alteração de direção tem os retornos desejados.
Você está investindo em soluções personalizadas em áreas com o maior valor agregado? Você sente fortemente que uma funcionalidade de plataforma de infraestrutura de aplicativo exclusiva faz parte de sua vantagem competitiva? Se você identificou lacunas, antes de fazer algo personalizado, considere em quais áreas os fornecedores são mais propensos a investir e concentrar seu pensamento personalizado em outro lugar. Comece pensando em si mesmo como um integrador em vez de uma infraestrutura de aplicativo personalizada ou um provedor de modelo de aplicativo. Tudo o que você construir terá que ser mantido, o que reduz os custos iniciais a longo prazo. Se você sentir a necessidade urgente de criar uma solução personalizada em uma área que você suspeita que será coberta por fornecedores a longo prazo, planeje o pôr do sol ou o suporte a longo prazo. Seus clientes internos normalmente ficarão tão felizes (se não mais) com um produto fora da prateleira como um personalizado.

Adaptar seus investimentos existentes na plataforma de aplicativos pode ser uma boa maneira de continuar. Ao fazer atualizações, considere começar com novos aplicativos para simplificar ideias de piloto antes de qualquer tipo de distribuição. Fator nessa alteração por meio de IaC e modelagem 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 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 mudanças ao longo do tempo.

Considerações sobre design e arquitetura

Embora existam vários padrões potenciais de plataforma de aplicativo que você pode usar, aqui estão algumas áreas comuns que são críticas, mas muitas vezes perdidas durante o design.

Gerenciamento de infraestrutura

Conforme mencionado em Aplicar sistemas de engenharia de software, a IaC 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 especificações 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 (alta computação, memória alta)
  • Categorias de tamanho do recurso (dimensionamento de camiseta, pequeno médio e grande.)

A meta 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 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. Nesta instância, as operações ou as equipes de engenharia de plataforma podem criar uma configuração única e 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 descompasso que podem corrigir automaticamente o descompasso (GitOps). Exemplos dessas ferramentas são ferramentas de IaC nativas do Terraform e da nuvem (exemplos, API de Cluster, Crossplane, Operador de Serviço do Azure v2). Fora da detecção de descompasso de ferramenta de IaC, há ferramentas de configuração de nuvem que podem consultar configurações de recursos, como Resource Graph do Azure. Eles podem servir como dois benefícios; você monitora alterações fora do código de infraestrutura e para 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 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ê terá 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. Por fim, há uma compensação entre a facilidade de uso e o controle que você precisa avaliar.

Durante o design da plataforma, avalie e priorize os serviços para os quais você deseja oferecer ou migrar. Por exemplo, se você cria aplicativos diretamente no Serviço de Kubernetes do Azure (AKS) ou por meio dos Aplicativos de Contêiner do Azure (ACA) depende dos 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 Azure Functions ou Serviço de Aplicativo do Azure. A ACA, Azure Functions 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 do 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 de IaC estabelecidos.

Os problemas que você identificou quando planejou devem ajudá-lo a avaliar qual final dessa escala é ideal para você. Certifique-se de fatorar seus próprios conjuntos de habilidades internos existentes à medida que você tomar uma decisão.

Recursos compartilhados versus dedicados

Em sua propriedade, há muitos recursos que podem ser compartilhados por vários aplicativos para aumentar a utilização e o custo-benefício. Cada um dos recursos que podem ser compartilhados tem seu próprio conjunto de considerações. Por exemplo, essas são considerações para compartilhar clusters K8s, mas algumas se aplicam a outros tipos de recursos:

  • Organização: O compartilhamento de recursos, como clusters dentro, e não entre outros, dos limites organizacionais pode melhorar a forma como eles se alinham à direção organizacional, aos requisitos, à prioridade etc.
  • Locação do aplicativo: Os aplicativos podem ter diferentes requisitos de isolamento de locação; você precisará examinar a segurança do aplicativo individual e a conformidade regulatória se ela puder 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 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 cada recurso de aplicativo, a capacidade de reposição 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). A meta é evitar mover seu aplicativo e dependências devido a restrições de recursos em um ambiente compartilhado ou ter incidentes de site dinâmico 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.
  • 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 de 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.

Alguns desses problemas são simplificados por soluções de PaaS, mas muitos desses pontos se aplicam até mesmo a algo como compartilhar um banco de dados. O compartilhamento tem ambos os lados para cima e para baixo e, portanto, você deve considerar as compensações cuidadosamente.

Para obter mais informações sobre o aspecto do cluster 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ção, mas a aplicação de regras de conformidade de uma maneira que não afeta o tempo de negócios para os aplicativos é um desafio comum. A governança é um tópico amplo, mas se esse for um problema que você está encontrando, tenha em mente os dois aspectos deste espaço:

  • Conformidade inicial da 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 (fique à direita): As ferramentas baseadas em política 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 K8s, juntamente com os OSs 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 Windows Política de Grupo, SELinux, AppArmor, Azure Policy ou Kyverno. Se os desenvolvedores tiverem acesso apenas a 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 (exemplo, Azure).

Manter a conformidade requer ferramentas para acessar, relatar e agir sobre problemas. Por exemplo, 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 evoluir para uma prática de PaC (política como código) ao operar em escala. Como uma parte fundamental do seu início à direita e manter a abordagem correta, o PaC fornece:

  • Padrões gerenciados centralmente
  • Controle de versão para suas políticas
  • Validação de & de teste automatizado
  • 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 & 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.

Observabilidade

Para dar suporte a seus aplicativos e infraestrutura, você precisará de observabilidade e registro em log 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 uma dashboard do Grafana.

No entanto, os requisitos diferem por função. Por exemplo, a equipe de engenharia e operações de plataforma exige que os painéis examinem a integridade e a capacidade da infraestrutura com alertas adequados. Os desenvolvedores exigem 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 resolve esses desafios, considere o seguinte:

  • Padrões: Aplique padrões de registro em log para facilitar a criação e 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 de equipe ou de nível de aplicativo usando algo como o Grafana para fornecer dados acumulados para qualquer pessoa interessada, juntamente com uma instalação para que membros confiáveis das equipes de aplicativos obtenham com segurança acesso 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 das diretrizes de 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. Quando possível, essas limitações devem ser fatoradas em modelos ou políticas de IaC usando ferramentas como Azure Policy. Em seguida, as operações devem monitorar proativamente o uso de painéis 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 K8s para capacidade, pois 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.
  • Identificar as principais métricas de capacidade e integridade: Monitore e alerte o sistema operacional e os recursos compartilhados (exemplos: CPU, memória, armazenamento) para a falta de coleta de métricas usando algo como o Prometheus ou o Azure Container Insights. Você pode monitorar soquetes/portas em uso, o 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 um alto nível, estes são alguns aspectos a serem considerados para sua plataforma:

  • Siga o princípio de privilégios mínimos.
  • Unificar o gerenciamento de segurança do DevOps em vários pipelines.
  • Verifique se os insights contextuais para identificar e corrigir seu risco mais crítico sã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 resolve problemas nessa área, você precisará 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, você desejará avaliar:

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, 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, infraestrutura em escala pode ser um desafio. Você desejará que os provedores de identidade criem, mantenham e gerenciem informações de identidade, fornecendo serviços de autenticação para aplicativos e serviços e que possam se integrar a sistemas de autorizações de controle de acesso baseado em função para o RBAC (gerenciamento de autenticação e autorização em escala). Por exemplo, você pode usar o RBAC do Azure e Microsoft Entra ID para fornecer autenticação e autorização em escala para serviços do Azure, como Serviço de Kubernetes do Azure sem a necessidade de 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 AKS, os aplicativos nativos de nuvem podem utilizar uma Identidade de Carga de Trabalho federada com Microsoft Entra ID para permitir que cargas de trabalho conteinerizadas se autentiquem. Essa abordagem permite que os aplicativos acessem recursos de nuvem sem trocas secretas no código do aplicativo.

Gerenciamento de custos de & de metadados

O custo é outro problema que pode chegar ao topo para seus esforços de 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ê desejará uma maneira de obter um inventário de recursos que mapeia para proprietários para um determinado conjunto de metadados. Por exemplo, no Azure, você pode usar rótulos aks, marcas de Resource Manager do Azure, 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 com o ressocimento de custos, o mapeamento de recursos da solução, os proprietários etc. Considere executar relatórios regulares para rastrear recursos órfãos.

Além do acompanhamento, 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 Gerenciamento de Custos da Microsoft. Embora esse método acompanhe os recursos provisionados pelas equipes de aplicativos, ele não abrange o custo de recursos compartilhados, como seu provedor de identidade, registro em log & 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ã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 custo em que possa examinar os gastos atuais. Por exemplo, em 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 limites predefinidos.

Criar uma base de autoatendimento do desenvolvedor