Partilhar via

Refinar a plataforma de aplicações

  • Artigo

Assim que compreender os problemas que pretende resolver primeiro no percurso de engenharia da plataforma, poderá ter de enfrentar alguns desafios com a sua plataforma de aplicações. Este artigo fornece algumas sugestões sobre como pode fazê-lo. Irá saber mais sobre os aspetos muitas vezes perdidos ou esquecidos da criação de uma plataforma de aplicações bem arquitetada. Especificamente, gestão de infraestrutura, segurança, gestão de custos, governação e observabilidade.

Decidir quando e onde investir

Se tiver uma ou mais plataformas de aplicações atualmente, pode ser difícil decidir quando e onde investir em melhorias que resolvam os problemas que identificou. Se estiver a começar de novo, o Centro de Arquitetura do Azure tem vários padrões potenciais para avaliar. Além disso, eis algumas perguntas a ter em conta à medida que começa a planear o que pretende fazer:

Pergunta Sugestões
Pretende adaptar a sua plataforma de aplicações existente, começar de novo ou utilizar uma combinação destas abordagens? Mesmo que esteja satisfeito com o que tem agora ou esteja a começar de novo, vai querer pensar em como se adaptar à mudança ao longo do tempo. O corte flash raramente funciona. Independentemente disso, tal como os sistemas de engenharia, as suas plataformas de aplicações são um destino em movimento. O que aterrar hoje vai mudar à medida que o tempo passa. Vai querer considerar este pensamento e quaisquer planos de migração relacionados para a sua conceção avançada. Saiba mais sobre a infraestrutura já abrangida como código (IaC) e abordagens de modelação em Aplicar sistemas de engenharia de software para o ajudar a gerir parte desta variação para novas aplicações.
Se quiser mudar o que está a fazer hoje, com que produtos, serviços ou investimentos está satisfeito? Como diz o ditado: "Se não estiver partido, não o corrijas." Não altere as coisas sem uma razão para o fazer. No entanto, se tiver alguma solução caseira, considere se está na altura de avançar para um produto existente para poupar na manutenção a longo prazo. Por exemplo, se estiver a operar a sua própria solução de monitorização, pretende remover essa carga da sua equipa de operações e migrar para um novo produto gerido?
Onde é que vê mais alterações a acontecer ao longo do tempo? Alguma destas opções é comum a todos (ou à maioria) dos tipos de aplicações da sua organização? As áreas com as quais você ou os seus clientes internos não estão satisfeitos e não são susceptíveis de mudar frequentemente são ótimos locais para começar. Estes têm o maior retorno do investimento a longo prazo. Isto também pode ajudá-lo a resolver como ajudaria a facilitar a migração para uma nova solução. Por exemplo, os modelos de aplicações tendem a ser fluidos, mas as ferramentas de análise de registos tendem a ter um prazo de validade mais longo. Também pode concentrar-se em novos projetos/aplicações a iniciar enquanto confirma que a alteração de direção tem os retornos pretendidos.
Está a investir em soluções personalizadas em áreas com o valor acrescentado mais elevado? Sente fortemente que uma capacidade de plataforma de infraestrutura de aplicações única faz parte da sua vantagem competitiva? Se identificou lacunas, antes de fazer algo personalizado, considere em que áreas é mais provável que os fornecedores invistam e concentre o seu pensamento personalizado noutro local. Comece por pensar em si próprio como um integrador em vez de uma infraestrutura de aplicações personalizada ou fornecedor de modelos de aplicações. Tudo o que construir terá de ser mantido, o que anã custa antecipadamente a longo prazo. Se sentir a necessidade urgente de criar uma solução personalizada numa área que suspeita que será abrangida por fornecedores a longo prazo, planeie o pôr-do-sol ou suporte a longo prazo. Normalmente, os seus clientes internos ficarão tão felizes (se não mais) com um produto fora da prateleira como um produto personalizado.

Adaptar os investimentos existentes na plataforma de aplicações pode ser uma boa forma de começar. Quando efetuar atualizações, considere começar com novas aplicações para simplificar as ideias de pilotagem antes de qualquer tipo de implementação. Factor nesta alteração através da templating iac e da aplicação. Invista em soluções personalizadas para as suas necessidades exclusivas em áreas de elevado impacto e valor elevado. Caso contrário, tente utilizar uma solução off-the-shelf. Tal como acontece com os sistemas de engenharia, concentre-se em automatizar o aprovisionamento, o controlo e a implementação em vez de assumir um caminho rígido para o ajudar a gerir as alterações ao longo do tempo.

Considerações de design e arquitetura

Embora existam vários padrões potenciais da plataforma de aplicações que pode utilizar, eis algumas áreas comuns que são críticas, mas muitas vezes perdidas durante a conceção.

Gestão da infraestrutura

Conforme mencionado em Aplicar sistemas de engenharia de software, a IaC e as ferramentas de automatização podem ser combinadas com modelos para uniformizar a implementação de aplicações e infraestruturas. Para reduzir o peso das especificações da plataforma no utilizador final, deve abstrair os detalhes da plataforma ao dividir as opções em convenções de nomenclatura relacionáveis, por exemplo:

  • Categorias de tipo de recurso (computação elevada, memória elevada)
  • Categorias de tamanho de recurso (tamanho da t-shirt, pequeno médio e grande.)

O objetivo deve ser ter modelos que representem requisitos gerais que tenham sido testados com configurações predefinidas, para que as equipas de desenvolvimento possam começar imediatamente a fornecer parâmetros mínimos e sem precisarem de rever as opções. No entanto, haverá ocasiões em que as equipas precisam de alterar mais opções em modelos publicados do que estão disponíveis ou desejáveis. Por exemplo, uma estrutura aprovada pode precisar de uma configuração específica que esteja fora das predefinições do modelo suportado. Nesta instância, as equipas de engenharia de plataformas ou operações podem criar uma configuração única e, em seguida, decidir se o modelo precisa de incorporar essas alterações como predefinição.

Pode controlar as alterações através de ferramentas IaC com funcionalidades de deteção de desfasamento que podem remediar automaticamente o desvio (GitOps). Exemplos destas ferramentas são as ferramentas IaC nativas do Terraform e da cloud (exemplos, API de Cluster, Crossplane, Operador de Serviço do Azure v2). Fora do desfasamento da ferramenta IaC, detete que existem ferramentas de configuração da cloud que podem consultar configurações de recursos, como o Azure Resource Graph. Estes podem servir como dois benefícios; monitorize as alterações fora do código da infraestrutura e reveja as configurações predefinidas alteradas. Para evitar ser demasiado rígido, também pode implementar tolerâncias em implementações com limites predefinidos. Por exemplo, pode utilizar Azure Policy para limitar o número de nós do Kubernetes que uma implementação pode ter.

Autogerido ou gerido?

Nas clouds públicas, terá a opção de consumir SaaS, PaaS ou IaaS. Para saber mais sobre SaaS, PaaS e IaaS, veja o módulo de preparação Descrever conceitos da cloud. Os serviços PaaS oferecem experiências de desenvolvimento simplificadas, mas são mais prescritivas com os respetivos modelos de aplicações. Em última análise, existe uma troca entre a facilidade de utilização e o controlo que precisa de avaliar.

Durante a conceção da plataforma, avalie e dê prioridade aos serviços que pretende oferecer ou mover. Por exemplo, se criar aplicações diretamente no Azure Kubernetes Service (AKS) ou através do Azure Container Apps (ACA) depende dos requisitos do serviço e da capacidade interna e do conjunto de competências. O mesmo se aplica a serviços de estilo de função, como Funções do Azure ou Serviço de Aplicações do Azure. A ACA, Funções do Azure e Serviço de Aplicações reduzir a complexidade, enquanto o AKS proporciona mais flexibilidade e controlo. Os modelos de aplicações mais experimentais, como o projeto de incubação OSS Radius , tentam fornecer um equilíbrio entre os dois, mas estão geralmente em fases anteriores de maturidade do que os serviços cloud com suporte total e presença em formatos IaC estabelecidos.

Os problemas que identificou quando planeou devem ajudá-lo a avaliar qual é o fim adequado para si. Certifique-se de que considera os seus próprios conjuntos de competências internos existentes à medida que tomar uma decisão.

Recursos partilhados vs. dedicados

No seu património, existem muitos recursos que podem ser partilhados por várias aplicações para aumentar a utilização e a relação custo-eficácia. Cada um dos recursos que podem ser partilhados tem o seu próprio conjunto de considerações. Por exemplo, estas são considerações para partilhar clusters K8s, mas algumas serão aplicadas a outros tipos de recursos:

  • Organização: Partilhar recursos como clusters dentro, em vez de atravessar, os limites organizacionais podem melhorar a forma como se alinham com a direção organizacional, os requisitos, a prioridade, etc.
  • Inquilino da aplicação: As aplicações podem ter diferentes requisitos de isolamento de inquilinos; terá de rever a segurança de aplicações individuais e a conformidade regulamentar se esta puder coexistir com outras aplicações. Por exemplo, no Kubernetes, as aplicações podem utilizar o isolamento do espaço de nomes. Mas também deve considerar o inquilino da aplicação para diferentes tipos de ambiente. Por exemplo, muitas vezes, é melhor evitar misturar aplicações de teste com aplicações de produção nos mesmos clusters para evitar impactos inesperados devido a configurações incorretas ou problemas de segurança. Em alternativa, pode optar por testar e otimizar primeiro os clusters do Kubernetes dedicados para detetar estes problemas antes da implementação num cluster partilhado. Independentemente disso, a consistência na sua abordagem é a chave para evitar confusões e erros.
  • Consumo de recursos: Compreenda a utilização de cada recurso da aplicação, a capacidade de reserva e faça uma projeção para estimar se a partilha é viável. Também deve estar ciente dos limites dos recursos consumidos (limites de subscrição ou capacidade do datacenter). O objetivo é evitar mover a aplicação e as dependências devido a restrições de recursos num ambiente partilhado ou a incidentes em direto do site devido ao esgotamento da capacidade. A utilização de limites de recursos, testes representativos, alertas de monitorização e relatórios pode ajudar a identificar o consumo de recursos e a proteger contra aplicações que consomem demasiados recursos que podem afetar outras aplicações.
  • Otimizar configurações partilhadas: Os recursos partilhados, como clusters partilhados, requerem consideração e configuração adicionais. Estas considerações incluem o carregamento cruzado, a alocação de recursos, a gestão de permissões, a propriedade da carga de trabalho, a partilha de dados, a coordenação de atualizações, o posicionamento da carga de trabalho, o estabelecimento, a gestão e a iteração de uma configuração de linha de base, gestão de capacidade e colocação de cargas de trabalho. Os recursos partilhados têm benefícios, mas se as configurações padrão forem demasiado restritivas e não evoluirem, tornar-se-ão obsoletas.

Alguns destes problemas são simplificados pelas soluções PaaS, mas muitos destes pontos aplicam-se a algo como partilhar uma base de dados. A partilha tem lados para cima e para baixo e, por isso, deve considerar cuidadosamente as trocas.

Para obter mais informações sobre o aspeto do cluster do Kubernetes deste artigo, veja a documentação multi-inquilinos do Azure Kubernetes Service (AKS).

Governação

A governação é uma parte fundamental da ativação da gestão personalizada com proteções, mas a aplicação de regras de conformidade de uma forma que não tenha impacto no tempo para o valor comercial das aplicações é um desafio comum. A governação é um tópico amplo, mas se este for um problema que está a encontrar, tenha em atenção ambos os aspetos deste espaço:

  • Conformidade de implementação inicial (iniciar à direita): Isto pode ser conseguido com modelos IaC padronizados que são disponibilizados através de catálogos, com gestão de permissões e políticas para garantir que apenas os recursos e configurações permitidos podem ser implementados.
  • Manter a conformidade (mantenha-se correto): As ferramentas baseadas em políticas podem impedi-lo ou alertá-lo quando existirem alterações de recursos. Além da sua infraestrutura principal, considere que as ferramentas também suportam a conformidade dentro de recursos, como K8s, juntamente com os SOs utilizados nos seus contentores ou VMs. Por exemplo, poderá querer impor uma configuração de SO bloqueada ou instalar ferramentas de software de segurança, como o Windows Política de Grupo, SELinux, AppArmor, Azure Policy ou Kyverno. Se os programadores só tiverem acesso aos repositórios IaC, pode adicionar fluxos de trabalho de aprovação para rever as alterações propostas e impedir o acesso direto a planos de controlo de recursos (por exemplo, o Azure).

Manter a conformidade requer ferramentas para aceder, comunicar e agir sobre problemas. Por exemplo, Azure Policy podem ser utilizados com muitos serviços do Azure para auditoria, relatórios e remediação. Também tem diferentes modos, como Auditoria, Negar e DeployIfNotExists, consoante as suas necessidades.

Embora as políticas possam impor a conformidade, também podem interromper aplicações inesperadamente. Por conseguinte, considere evoluir para uma política como prática de código (PaC) ao operar em escala. Como parte fundamental do seu direito de início e manter a abordagem certa, o PaC fornece:

  • Normas geridas centralmente
  • Controlo de versões para as suas políticas
  • Validação de & de teste automatizada
  • Tempo de implementação reduzido
  • Implementação contínua

A PaC pode ajudar a minimizar o raio de explosão de uma política potencialmente má com capacidades como:

  • Definições de política armazenadas como código num repositório que é revisto e aprovado.
  • Automatização para fornecer testes e validação.
  • A implementação gradual de políticas baseadas em anel & remediação em recursos existentes ajuda a minimizar o raio de explosão de uma política potencialmente má.
  • A tarefa de remediação tem segurança incorporada, com controlos como parar a tarefa de remediação se mais de 90% das implementações falharem.

Observabilidade

Para suportar as suas aplicações e infraestrutura, precisará de observabilidade e registo em toda a pilha que as suas equipas de engenharia, operações e programadores da plataforma podem utilizar para ver o que está a acontecer.

Ilustração de um dashboard do Grafana.

No entanto, os requisitos diferem por função. Por exemplo, a equipa de engenharia e operações da plataforma requer dashboards para rever o estado de funcionamento e a capacidade da infraestrutura com alertas adequados. Os programadores precisam de métricas de aplicações, registos e rastreios para resolver problemas e dashboards personalizados que mostrem o estado de funcionamento da aplicação e da infraestrutura. Um dos problemas que qualquer uma destas funções pode estar a encontrar é a sobrecarga cognitiva de demasiadas informações ou lacunas de conhecimento devido à falta de informações úteis.

Para resolver estes desafios, considere o seguinte:

  • Normas: Aplique padrões de registo para facilitar a criação e reutilização de dashboards padronizados e simplificar o processamento de ingestão através de algo como a arquitetura de observabilidade OpenTelemetry.
  • Permissões: Considere fornecer dashboards ao nível da equipa ou da aplicação através de algo como o Grafana para fornecer dados agregados para qualquer pessoa interessada, juntamente com uma instalação para membros fidedignos das equipas de aplicações obterem acesso aos registos de forma segura quando necessário.
  • Retenção: A retenção de registos e métricas pode ser dispendiosa e pode criar riscos inesperados ou violações de conformidade. Estabeleça as predefinições de retenção e publique-as como parte da sua documentação de orientação de início correto.
  • Monitorizar limites de recursos: As equipas de operações devem conseguir identificar e controlar quaisquer limitações para um determinado tipo de recurso. Sempre que possível, estas limitações devem ser tidas em conta em modelos ou políticas IaC com ferramentas como Azure Policy. Em seguida, as operações devem monitorizar proativamente a utilização de dashboards em algo como o Grafana e expandir os recursos partilhados onde o dimensionamento automatizado não é possível ou ativado. Por exemplo, monitorize o número de nós de cluster K8s para capacidade à medida que as aplicações são integradas e modificadas ao longo do tempo. Os alertas são necessários e estas definições devem ser armazenadas como código para que possam ser adicionadas programaticamente aos recursos.
  • Identifique as principais métricas de capacidade e estado de funcionamento: Monitorize e alerte o SO e os recursos partilhados (exemplos: CPU, memória, armazenamento) para eliminação com a recolha de métricas com algo como o Prometheus ou o Azure Container Insights. Pode monitorizar sockets/portas em utilização, o consumo de largura de banda de rede de aplicações chatty e o número de aplicações com estado alojadas no cluster.

Segurança

A segurança é necessária em todas as camadas, desde código, contentor, cluster e cloud/infraestrutura. Cada organização tem os seus próprios requisitos de segurança, mas a um nível elevado, estas são algumas coisas a considerar para a sua plataforma:

  • Siga o princípio do menor privilégio.
  • Unifique a gestão de segurança do DevOps em vários pipelines.
  • Certifique-se de que as informações contextuais para identificar e remediar o risco mais crítico estão visíveis.
  • Ative a deteção e resposta a ameaças modernas nas cargas de trabalho na cloud durante o runtime.

Para ajudar a resolver problemas nesta área, precisará de ferramentas para avaliar ferramentas que funcionam em todos os sistemas, recursos e serviços de engenharia e aplicações em clouds e híbridos (por exemplo, Microsoft Defender para a Cloud). Para além da segurança da aplicação, vai querer avaliar:

Os requisitos de permissões podem ser diferentes por ambiente. Por exemplo, em algumas organizações, as equipas individuais não têm permissão para aceder a recursos de produção e as novas aplicações não podem ser implementadas automaticamente até que as revisões estejam concluídas. No entanto, em ambientes de desenvolvimento e teste, a implementação automatizada de recursos e aplicações e o acesso a clusters para resolução de problemas podem ser permitidos.

Gerir o acesso de identidade a serviços, aplicações e infraestruturas em escala pode ser um desafio. Vai querer que os fornecedores de identidade criem, mantenham e giram informações de identidade ao mesmo tempo que fornecem serviços de autenticação a aplicações e serviços e que podem ser integrados com sistemas de autorizações de controlo de acesso baseado em funções para gestão de autenticação e autorização em escala (RBAC). Por exemplo, pode utilizar o RBAC do Azure e Microsoft Entra ID para fornecer autenticação e autorização em escala para serviços do Azure, como Azure Kubernetes Service sem ter de configurar permissões diretamente em cada cluster individual.

As aplicações podem precisar de acesso a uma identidade para aceder a recursos na cloud, como o armazenamento. Tem de rever os requisitos e avaliar a forma como o seu fornecedor de identidade pode suportar isto da forma mais segura possível. Por exemplo, no AKS, as aplicações nativas da cloud podem utilizar uma Identidade da Carga de Trabalho que federa com Microsoft Entra ID para permitir a autenticação de cargas de trabalho em contentores. Esta abordagem permite que as aplicações acedam a recursos da cloud sem trocas de segredos no código da aplicação.

Metadados & gestão de custos

O custo é outro problema que pode surgir no topo para os seus esforços de engenharia de plataforma. Para gerir corretamente a sua plataforma de aplicações, precisa de uma forma de identificar os proprietários das cargas de trabalho. Vai querer obter uma forma de obter um inventário de recursos que mapeie aos proprietários para um determinado conjunto de metadados. Por exemplo, no Azure, pode utilizar Etiquetas do AKS, etiquetas de Resource Manager do Azure, juntamente com conceitos como projetos em Ambientes de Implementação do Azure para agrupar os seus recursos a diferentes níveis. Para que isto funcione, os metadados escolhidos têm de incluir propriedades obrigatórias (utilizando algo como Azure Policy) ao implementar cargas de trabalho e recursos. Isto ajuda com a atribuição de custos, mapeamento de recursos da solução, proprietários, etc. Considere executar relatórios regulares para controlar recursos órfãos.

Além do controlo, poderá ter de atribuir custos a equipas de aplicações individuais para a utilização de recursos através destes mesmos metadados com sistemas de gestão de custos, como o Microsoft Cost Management. Embora este método acompanhe os recursos aprovisionados pelas equipas de aplicações, não abrange o custo dos recursos partilhados, como o seu fornecedor de identidade, o registo & armazenamento de métricas e o consumo de largura de banda de rede. Para recursos partilhados, pode dividir igualmente os custos operacionais pelas equipas individuais ou fornecer sistemas dedicados (por exemplo, armazenamento de registo) onde existe um consumo não uniforme. Alguns tipos de recursos partilhados poderão fornecer informações sobre o consumo de recursos, por exemplo, o Kubernetes tem ferramentas como o OpenCost ou o Kubecost e pode ajudar.

Também deve procurar ferramentas de análise de custos, onde pode rever os gastos atuais. Por exemplo, no portal do Azure existem alertas de custos e alertas de orçamentos que podem controlar o consumo de recursos num grupo e enviar notificações quando atinge limiares predefinidos.

Criar uma base self-service para programadores