Desenvolvimento de um aplicativo de 12 fatores no Google Cloud

Last reviewed 2023-09-14 UTC

Este documento descreve a conhecida metodologia de aplicativo de 12 fatores e como aplicá-la ao desenvolver aplicativos executados no Google Cloud. Se você usar essa metodologia, poderá criar aplicativos escalonáveis e resilientes que podem ser implantados continuamente com o máximo de agilidade.

Este documento é destinado a desenvolvedores familiarizados com o Google Cloud, controle de versões, integração contínua e tecnologia de contêiner.

Introdução

Os desenvolvedores estão migrando aplicativos para a nuvem e, ao fazer isso, eles se tornam mais experientes na criação e implantação desses aplicativos. Dessa experiência, surgiu um conjunto de práticas recomendadas, conhecidas como os 12 fatores. Ao desenvolver um aplicativo com esses fatores em mente, é possível implantar aplicativos na nuvem que sejam mais portáteis e resilientes quando comparados a aplicativos implantados em ambientes locais, levando mais tempo para provisionar novos recursos.

No entanto, desenvolver aplicativos modernos nativos da nuvem requer uma mudança na maneira como você pensa em engenharia, configuração e implantação de software, em comparação com o desenvolvimento de aplicativos para ambientes locais. Este documento ajuda você a entender como aplicar os 12 fatores ao desenvolvimento do seu aplicativo.

Vantagens de aplicativos de 12 fatores

O design de 12 fatores também ajuda a separar componentes do aplicativo, de modo que cada componente possa ser substituído facilmente ou dimensionado para cima ou para baixo sem problemas. Como os fatores são independentes de qualquer linguagem de programação ou pilha de software, o design de 12 fatores pode ser aplicado a uma ampla variedade de aplicativos.

Os 12 fatores

1. Codebase

Você precisa acompanhar o código do seu aplicativo em um sistema de controle de versões, como o Git ou o Mercurial. Você trabalha no aplicativo verificando o código no seu ambiente de desenvolvimento local. Armazenar o código em um sistema de controle de versões permite que sua equipe trabalhe em conjunto fornecendo uma trilha de auditoria das alterações no código, uma maneira sistematizada de resolver conflitos de mesclagem e a capacidade de reverter o código para uma versão anterior. Ele também fornece um local de onde fazer a integração contínua (CI) e a implantação contínua (CD).

Embora os desenvolvedores estejam trabalhando em diferentes versões do código nos seus ambientes de desenvolvimento, a qualquer momento a fonte da verdade é o código no sistema de controle de versões. O código no repositório é o que é construído, testado e implantado, e o número de repositórios é independente do número de ambientes. O código no repositório é usado para produzir uma única compilação, que é combinada com a configuração específica do ambiente para produzir uma versão imutável, uma versão em que nenhuma alteração pode ser feita, incluindo a configuração, que pode ser implantada em um ambiente. (Todas as alterações necessárias para a versão precisam resultar em uma nova versão.)

2. Dependências

Há duas considerações quando se trata de dependências para aplicativos de 12 fatores: declaração de dependência e isolamento de dependência.

Apps de 12 fatores nunca precisam ter dependências implícitas. Você precisa declarar as dependências explicitamente e verificar essas dependências no controle de versões. Isso permite que você comece a usar o código rapidamente de modo repetível e facilita o rastreamento de alterações às dependências. Muitas linguagens de programação oferecem uma maneira de declarar explicitamente dependências, como pip para Python e Bundler para Ruby.

Você também precisa isolar um aplicativo e suas dependências empacotando-os em um contêiner. Os contêineres permitem isolar um aplicativo e suas dependências do ambiente e garantir que o aplicativo funcione de maneira uniforme, independentemente das diferenças entre ambientes de desenvolvimento e de teste.

O Artifact Registry é um serviço de gerenciamento de artefatos privados totalmente gerenciado que oferece suporte a vários tipos de artefatos, como imagens de contêiner, pacotes de linguagens (como Maven e npm) e pacotes de SO (como RPM). Para ajudar a gerenciar os resultados dos builds de CI/CD e as dependências deles, use o Cloud IAM com o Artifact Registry com o controle de acesso refinado. O Artifact Analysis detecta vulnerabilidades em imagens de contêiner enviadas ao Artifact Registry para garantir que elas sejam seguras para implantação.

As integrações existentes de CI e CD também permitem que você configure pipelines totalmente automatizados para receber feedback rápido. É possível enviar imagens para o registro e extrair imagens usando um endpoint HTTP de qualquer máquina, seja uma instância do Compute Engine ou seu próprio hardware.

3. Configuração

Cada aplicativo moderno requer alguma forma de configuração. Geralmente, você tem configurações diferentes para cada ambiente, como desenvolvimento, teste e produção. Essas configurações geralmente incluem credenciais de conta de serviço e identificadores de recursos para serviços de backup, como bancos de dados.

As configurações de cada ambiente precisam ser externas ao código e não precisam ser verificadas no controle de versões. Todos trabalham em apenas uma versão do código, mas você tem várias configurações. O ambiente de implantação determina qual configuração usar. Isso permite que uma versão do binário seja implantada em cada ambiente, em que a única diferença é a configuração do ambiente de execução. Uma maneira fácil de verificar se a configuração foi externalizada corretamente é ver se o código pode se tornar público sem revelar credenciais.

Uma forma de externalizar a configuração é criar arquivos de configuração. No entanto, os arquivos de configuração geralmente são específicos de uma linguagem ou estrutura de desenvolvimento.

Uma abordagem melhor é armazenar a configuração nas variáveis de ambiente. Elas são fáceis de alterar para cada ambiente de execução, provavelmente não serão verificados no controle de versões e são independentes da linguagem de programação e da estrutura de desenvolvimento. No Google Kubernetes Engine (GKE), é possível usar ConfigMaps. Isso permite vincular variáveis de ambiente, números de porta, arquivos de configuração, argumentos de linha de comando e outros artefatos de configuração aos contêineres e componentes do sistema dos pods no ambiente de execução.

O Cloud Functions e o Cloud Run aceitam o uso de variáveis de ambiente. É possível externalizar e modificar configurações no console do Google Cloud ou usando o SDK Google Cloud.

4. Serviços de apoio

Todo serviço que o aplicativo consome como parte da operação normal, como sistemas de arquivos, bancos de dados, sistemas de armazenamento em cache e filas de mensagens, precisa ser acessado como um serviço e externalizado na configuração. Você precisa pensar nesses serviços de apoio como abstrações para o recurso subjacente. Por exemplo, quando o aplicativo grava dados no armazenamento, tratar o armazenamento como um serviço de backup permite alterar perfeitamente o tipo de armazenamento subjacente, porque ele é separado do aplicativo. Em seguida, é possível executar uma alteração, como alternar de um banco de dados local do PostgreSQL para o Cloud SQL para PostgreSQL sem alterar o código do aplicativo.

5. Criar, lançar, executar

É importante separar o processo de implantação do software em três estágios distintos: compilar, lançar e executar. Cada estágio precisa resultar em um artefato que seja exclusivamente identificável. Toda implantação precisa ser vinculada a uma versão específica resultante da combinação da configuração de um ambiente com uma versão. Isso permite reversões fáceis e uma trilha de auditoria visível do histórico de cada implantação de produção.

É possível acionar manualmente o estágio de criação, mas ele geralmente é acionado de modo automático quando você confirma o código que passou em todos os testes necessários. O estágio de criação usa o código, busca as bibliotecas e os recursos necessários e os empacota em um binário ou contêiner independente. O resultado do estágio de criação é um artefato de criação.

Quando o estágio de versão é concluído, o estágio de lançamento combina o artefato de construção com a configuração de um ambiente específico. Isso produz uma versão. A versão pode ser implantada automaticamente no ambiente por um aplicativo de implantação contínua. Ou é possível acionar a versão pelo mesmo aplicativo de implantação contínua.

Finalmente, o estágio de execução inicia a versão e a inicia. Por exemplo, se você estiver implantando no GKE, o Cloud Build vai poder chamar a etapa de versão gke-deploy para implantar no cluster do GKE. O Cloud Build pode gerenciar e automatizar os estágios de compilação, lançamento e execução em vários idiomas e ambientes usando arquivos de configuração de compilação no formato YAML ou JSON.

Além disso, é possível usar o Cloud Deploy, que é um serviço totalmente gerenciado que fornece uma entrega contínua para o GKE, o Cloud Run e o Anthos. Com o Cloud Deploy, é possível criar um pipeline de entrega que inclui etapas de aprovação e promoção contínua para vários ambientes. Além disso, o Cloud Deploy oferece suporte à reversão de uma etapa de um aplicativo implantado em qualquer destino.

6. Processos

Você executa aplicativos de 12 fatores no ambiente como um ou mais processos. Esses processos precisam ser sem estado e não precisam compartilhar dados entre si. Isso permite que os aplicativos aumentem com a replicação dos processos. Criar aplicativos sem estado também torna os processos portáteis em toda a infraestrutura de computação.

Se você está acostumado com o conceito de sessões "fixas", isso exige uma mudança na forma como você lida com o gerenciamento e a persistência de dados. Como os processos podem desaparecer a qualquer momento, não é possível confiar no conteúdo do armazenamento local ou em qualquer solicitação subsequente que será processada pelo mesmo processo. Portanto, você precisa manter explicitamente todos os dados que precisam ser reutilizados em um serviço de apoio externo, como um banco de dados.

Se você precisar manter os dados, poderá usar o Memorystore e o Filestore para armazenar em cache o estado dos seus aplicativos e compartilhar dados comuns entre processos para incentivar o acoplamento flexível.

7. Vinculação de portas

Em ambientes que não sejam de nuvem, os aplicativos da Web geralmente são criados para execução em contêineres de aplicativos, como GlassFish, Apache Tomcat e Apache HTTP Server. Por outro lado, aplicativos de 12 fatores não dependem de contêineres de aplicativos externos. Em vez disso, eles agrupam a biblioteca do servidor da Web como parte do próprio aplicativo.

São práticas recomendadas de arquitetura para que os serviços exponham um número de porta, especificado pela variável de ambiente PORT.

Os aplicativos que exportam a vinculação de portas são capazes de consumir informações de vinculação de portas externamente (como variáveis de ambiente) ao usar o modelo de plataforma como um serviço. No Google Cloud, é possível implantar aplicativos em serviços de plataforma, como Compute Engine, GKE, App Engine ou Cloud Run.

Nesses serviços, uma camada de roteamento encaminha solicitações de um nome de host público para seus processos da Web vinculados à porta. Por exemplo, ao implantar seus aplicativos no App Engine, você declara dependências para adicionar uma biblioteca de servidor da Web ao aplicativo, como Express (para Node.js), Flask e Gunicorn (para Python) ou Jetty (para Java).

Você não precisa codificar números de porta em seu código. Em vez disso, forneça os números de porta no ambiente, como em uma variável de ambiente. Isso torna seus aplicativos portáteis quando você os executa no Google Cloud.

Como o Kubernetes tem descoberta de serviço integrada, no Kubernetes é possível abstrair as vinculações de porta mapeando as portas de serviço para contêineres. A descoberta de serviço é realizada usando nomes DNS internos.

Em vez de codificar a porta que o servidor da Web detecta, a configuração usa uma variável de ambiente. O snippet de código a seguir de um aplicativo do App Engine mostra como aceitar um valor de porta passado em uma variável de ambiente.

const express = require('express')
const request = require('got')

const app = express()
app.enable('trust proxy')

const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
  console.log('App listening on port ${PORT}')
  console.log('Press Ctrl+C to quit.')
})

8. Simultaneidade

Decomponha seu aplicativo em processos independentes com base em tipos de processo, como processos em segundo plano, da Web e de trabalho. Isso permite que o aplicativo seja escalonado com base nos requisitos de carga de trabalho individuais. A maioria dos aplicativos nativos da nuvem permite escalonamento sob demanda. Desenvolva o aplicativo como vários processos distribuídos que podem executar blocos de trabalho de forma independente e escalonar, adicionando mais processos.

As seções a seguir descrevem alguns constructos para permitir que os aplicativos sejam escalonados. Os aplicativos criados com os princípios de descartabilidade e sem estado estão bem posicionados para ganhar com esses constructos de escalonamento horizontal.

Usando o Cloud Run

O Cloud Run é uma plataforma de computação que permite executar contêineres diretamente na infraestrutura gerenciada pelo Google. O Cloud Run tem duas maneiras de executar seu código. Cloud Run services é executado continuamente como um serviço. Geralmente, é usado para responder a solicitações ou eventos da Web. Cloud Run jobs executa o código que executa um trabalho de job específico e é encerrado quando o trabalho é concluído. O Cloud Run também oferece o Cloud Scheduler para executar jobs em lote. Essa estrutura é adequada para implementar simultaneidade e escalonar possíveis arquiteturas de serviço.

Para mais informações sobre o Cloud Run, consulte O que é o Cloud Run.

Como usar o Cloud Functions

O Cloud Functions são funções sem estado e de finalidade única executadas no Google Cloud, em que a arquitetura subjacente em que são executadas é gerenciada pelo Google. O Cloud Functions responde a gatilhos de eventos, como um upload para um bucket do Cloud Storage ou uma mensagem do Pub/Sub. Cada invocação de função responde a um único evento ou solicitação.

O Cloud Functions lida com as solicitações recebidas atribuindo-as a instâncias da sua função. Quando o volume de solicitações de entrada excede o número de instâncias existentes, o Cloud Functions pode iniciar novas instâncias para processar solicitações. Esse comportamento de escalonamento automático e totalmente gerenciado permite que o Cloud Functions processe muitas solicitações em paralelo, cada uma usando uma instância diferente da função.

Como usar o App Engine

É possível hospedar seus aplicativos na infraestrutura gerenciada do Google Cloud usando o Google App Engine. As instâncias são as unidades de computação que o App Engine usa para escalonar automaticamente seu aplicativo. A qualquer momento, o aplicativo pode estar em execução em uma ou em várias instâncias, com solicitações espalhadas por todas elas.

O programador do App Engine decide como exibir cada nova solicitação. O programador pode usar uma instância existente (uma inativa ou uma que aceita solicitações simultâneas), colocar a solicitação em uma fila de solicitações pendentes ou iniciar uma nova instância para essa solicitação. A decisão considera o número de instâncias disponíveis, a rapidez com que o aplicativo veicula solicitações (sua latência) e quanto tempo leva para iniciar uma nova instância.

Se você usar o escalonamento automático, poderá criar um equilíbrio entre desempenho e custo definindo a utilização de CPU de destino, a capacidade de destino e o máximo de solicitações simultâneas.

É possível especificar o tipo de escalonamento no arquivo app.yaml, que pode ser carregado para sua versão de serviço. Com base nessa entrada de configuração, a infraestrutura do App Engine usa instâncias dinâmicas ou residentes. Para mais informações sobre tipos de escalonamento, consulte a documentação do App Engine.

Como usar o escalonamento automático do GKE

Há alguns constructos importantes do Kubernetes aplicáveis aos processos de escalonamento:

  • Escalonamento automático horizontal de pods (HPA). O Kubernetes pode ser configurado para aumentar ou diminuir o número de pods em execução no cluster com base em métricas personalizadas ou padrão. Isso é útil quando você precisa responder a uma carga variável no cluster do GKE.

  • Escalonamento automático de nós. Em tempos de maior demanda, talvez seja necessário escalonar o cluster para acomodar mais pods. Com o GKE, é possível configurar seu cluster de forma declarativa para escalonar. Com o escalonamento automático ativado, o GKE faz o escalonamento automático dos nós quando outros pods precisam ser programados e quando os nós existentes não podem acomodá-los. O GKE também reduz os nós quando o carregamento no cluster diminui, de acordo com os limites que você configurou.

  • Jobs. O GKE é compatível com jobs do Kubernetes. Um job pode ser amplamente definido como uma tarefa que precisa de um ou mais pods para ser executada. O job pode ser executado uma vez ou em uma programação. Os pods em que o job é executado são descartados quando o job é concluído. O arquivo YAML que configura o job especifica detalhes sobre o tratamento de erros, paralelismo, como as reinicializações são processadas e assim por diante.

Como usar o Compute Engine

Como alternativa, é possível implantar e gerenciar seus aplicativos no Compute Engine. Nesse caso, é possível escalonar o aplicativo para responder a cargas variáveis usando grupos gerenciados de instâncias (MIG) com base na utilização da CPU, solicitações sendo processadas ou outros sinais de telemetria do aplicativo.

A figura a seguir ilustra os principais recursos que os grupos gerenciados de instâncias fornecem.

Visão geral dos recursos do MIG e cargas de trabalho comuns

O uso de grupos gerenciados de instâncias permite que o aplicativo seja escalonado de acordo com a demanda recebida e esteja altamente disponível. Esse conceito funciona bem para aplicativos sem estado, como front-ends da Web e para cargas de trabalho de alto desempenho baseadas em lote.

9. Descartabilidade

Para aplicativos executados na infraestrutura em nuvem, trate os aplicativos e a infraestrutura subjacente como recursos descartáveis. Seus aplicativos precisam ser capazes de lidar com a perda temporária da infraestrutura subjacente e de encerrar e reiniciar.

Os principais princípios a serem considerados incluem:

  • Separe a funcionalidade como gerenciamento de estado e armazenamento de dados transacionais usando serviços de backup. Para mais informações, consulte Serviços de apoio anteriormente neste documento.
  • Gerencie variáveis de ambiente fora do aplicativo para que possam ser usadas no ambiente de execução.
  • Verifique se o tempo de inicialização é mínimo. Isso significa que você precisa decidir quantas camadas criar em imagens ao usar máquinas virtuais, como imagens públicas versus personalizadas. Essa decisão é específica para cada aplicativo e precisa ser baseada nas tarefas executadas pelos scripts de inicialização. Por exemplo, se você estiver fazendo o download de vários pacotes ou binários e inicializando-os durante a inicialização, uma parte significativa do tempo de inicialização será dedicada à conclusão dessas tarefas.
  • Use recursos nativos do Google Cloud para realizar tarefas de infraestrutura. Por exemplo, é possível usar atualizações contínuas no GKE e gerenciar suas chaves de segurança usando o Cloud Key Management Service (Cloud KMS).

  • Use o sinal SIGTERM (quando disponível) para iniciar um encerramento limpo. Por exemplo, quando o App Engine Flex encerra uma instância, normalmente envia um sinal STOP (SIGTERM) para o contêiner do aplicativo. Seu aplicativo pode usar esse sinal para executar qualquer ação de limpeza antes que o contêiner seja encerrado. (O aplicativo não precisa responder ao evento SIGTERM.) Em condições normais, o sistema aguarda até 30 segundos para que o aplicativo pare e, em seguida, envia um sinal KILL (SIGKILL).

    O snippet a seguir em um aplicativo do App Engine mostra como é possível interceptar o sinal SIGTERM para fechar as conexões de banco de dados abertas.

    const express = require('express')
const dbConnection = require('./db')

// Other business logic related code

app.listen(PORT, () => {
  console.log('App listening on port ${PORT}')
  console.log('Press Ctrl+C to quit.')
})

process.on('SIGTERM', () => {
  console.log('App Shutting down')
  dbConnection.close()  // Other closing of database connection
})

10. Paridade de ambiente

Os aplicativos empresariais se movem por diferentes ambientes durante o ciclo de vida de desenvolvimento. Normalmente, esses ambientes são desenvolvimento, teste e organização e produção. É uma prática recomendada manter esses ambientes o mais semelhantes possível.

A paridade de ambiente é um recurso que a maioria dos desenvolvedores considera adequada. No entanto, à medida que as empresas crescem e seus ecossistemas de TI evoluem, a paridade do ambiente fica mais difícil de manter.

Manter a paridade de ambiente ficou mais fácil nos últimos anos porque os desenvolvedores adotaram o controle de origem, o gerenciamento de configuração e os arquivos de configuração de modelo. Isso facilita a implantação de um aplicativo em vários ambientes de forma consistente. Por exemplo, usando o Docker e o Docker Compose, é possível garantir que a pilha do aplicativo mantenha a forma e a instrumentação em ambientes diferentes.

A tabela a seguir lista os serviços e as ferramentas do Google Cloud que é possível usar ao projetar aplicativos para execução no Google Cloud. Esses componentes servem a diferentes finalidades e ajudam você a criar fluxos de trabalho coletivamente que deixam seus ambientes mais consistentes.

Componente do Google Cloud Purpose
Artifact Registry Um gerenciador de pacotes universal para todos os artefatos e dependências de compilação.
Cloud Build Um serviço totalmente gerenciado que executa os builds na infraestrutura do Google Cloud.
Cloud KMS Armazene suas chaves criptográficas em um serviço de nuvem central para uso direto por outros recursos e aplicativos de nuvem.
Cloud Storage Armazene imagens personalizadas criadas com base em discos de origem, imagens, instantâneos ou imagens armazenadas no Cloud Storage. É possível usar essas imagens para criar instâncias de máquina virtual (VM, na sigla em inglês) personalizadas para seus aplicativos.
Cloud Deploy Forneça entrega automatizada dos aplicativos a uma série de vários ambientes de destino em uma sequência definida.

11. Registros

Os registros informam sobre a integridade dos seus aplicativos. É importante dissociar a coleta, o processamento e a análise de registros da lógica principal de seus aplicativos. A separação de registros é particularmente útil quando seus aplicativos exigem escalonamento dinâmico e estão sendo executados em nuvens públicas, porque elimina a sobrecarga de gerenciamento do local de armazenamento para registros e a agregação de VMs distribuídas (e geralmente temporárias).

O Google Cloud oferece um conjunto de ferramentas que ajudam na coleta, processamento e análise estruturada de registros. É uma boa prática instalar o agente do Cloud Logging nas VMs do Compute Engine. (Por padrão, o agente é pré-instalado nas imagens de VM do App Engine e do GKE.) O agente monitora um conjunto pré-configurado de locais de registro. Os registros gerados pelos aplicativos em execução na VM são coletados e transmitidos para o Cloud Logging.

Quando a geração de registros é ativada para um cluster do GKE, um agente de geração de registros é implantado em todos os nós que fazem parte do cluster. O agente coleta registros, enriquece os registros com metadados relevantes e os mantém em um armazenamento de dados. Esses registros estão disponíveis para revisão usando o Cloud Logging. Se você precisar de mais controle sobre o que é registrado, use os daemonsets do Fluentd.

Para mais informações, consulte Configurar o agente do Logging.

12. Processos de administração

Os processos administrativos geralmente consistem em tarefas pontuais ou tarefas cronometradas e recorrentes, como gerar relatórios, executar scripts em lote, iniciar backups de bancos de dados e migrar esquemas. O fator de processo do administrador no manifesto de 12 fatores foi desenvolvido pensando em tarefas únicas. Para aplicativos nativos da nuvem, esse fator se torna mais relevante ao criar tarefas recorrentes e a orientação nesta seção é voltada para tarefas como essas.

Os acionadores cronometrados geralmente são criados como cron jobs e gerenciados inerentemente pelos próprios aplicativos. Esse modelo funciona, mas introduz uma lógica que está altamente associada ao aplicativo e que requer manutenção e coordenadas, especialmente se os aplicativos estiverem distribuídos entre fusos horários.

Portanto, ao desenvolver para processos administrativos, você precisa separar o gerenciamento dessas tarefas do próprio aplicativo. Dependendo das ferramentas e da infraestrutura em que seu aplicativo é executado, use as seguintes sugestões:

  • Para executar aplicativos no GKE, inicie contêineres separados para tarefas de administrador. É possível aproveitar os CronJobs no GKE. Os CronJobs são executados em contêineres efêmeros e permitem controlar o tempo, a frequência de execução e as novas tentativas se os jobs falharem ou forem muito longos para serem concluídos.
  • Para hospedar aplicativos no App Engine ou Compute Engine, é possível externalizar o mecanismo de acionamento e criar um endpoint para o gatilho invocar. Essa abordagem ajuda a definir um limite ao qual os aplicativos são responsáveis, em contraste com o foco de finalidade única do endpoint. O Cloud Tasks é um serviço de execução de tarefas totalmente gerenciado e assíncrono que pode ser usado para implementar esse padrão com o App Engine. Também é possível usar o Cloud Scheduler, um programador totalmente gerenciado de nível empresarial no Google Cloud, para acionar operações cronometradas.

Indo além dos 12 fatores

Os 12 fatores descritos neste documento oferecem orientações sobre como abordar a criação de aplicativos nativos da nuvem. Esses aplicativos são os alicerces fundamentais de uma empresa.

Uma empresa típica tem muitos aplicativos como esses, muitas vezes desenvolvidos por várias equipes de forma colaborativa para oferecer capacidade de negócios. É importante estabelecer alguns princípios adicionais durante o ciclo de desenvolvimento do aplicativo, e não como uma reflexão tardia, para abordar como os aplicativos se comunicam entre si e como eles são protegidos e controlados.

As seções a seguir descrevem algumas dessas considerações adicionais que você precisa fazer durante o design e o desenvolvimento do aplicativo.

Pense na API primeiro

Os aplicativos se comunicam usando APIs. Ao criar aplicativos, pense em como o aplicativo será consumido pelo ecossistema dele e comece criando uma estratégia de API. Um bom design de API facilita o consumo da API por desenvolvedores de aplicativos e partes interessadas externas. É uma boa prática começar documentando a API por meio da especificação OpenAPI antes de implementar qualquer código.

As APIs abstraem a funcionalidade subjacente do aplicativo. Um endpoint de API bem desenvolvido precisa isolar e separar os aplicativos de consumo da infraestrutura de aplicativos que fornece o serviço. Esse dissociação permite alterar o serviço subjacente e a infraestrutura dele de maneira independente, sem afetar os consumidores do aplicativo.

É importante catalogar, documentar e publicar as APIs que você desenvolve para que os consumidores das APIs possam descobri-las e usá-las. O ideal é que os consumidores da API atendam a si mesmos. Para fazer isso, crie um portal para desenvolvedores. Um portal do desenvolvedor serve como ponto de entrada para todos os consumidores da API, internos para a empresa, ou externos para consumidores, como desenvolvedores do ecossistema de parceiros.

O Apigee, o pacote de produtos de gerenciamento de APIs do Google, ajuda você a gerenciar todo o ciclo de vida das suas APIs, desde a criação até a publicação.

Segurança

O domínio da segurança é amplo e inclui sistemas operacionais, redes e firewalls, segurança de dados e banco de dados, segurança de aplicativos e gerenciamento de identidade e acesso. É de suma importância abordar todas as dimensões de segurança no ecossistema de uma empresa.

Do ponto de vista de um aplicativo, as APIs fornecem acesso aos aplicativos no ecossistema da sua empresa. Portanto, verifique se esses elementos básicos têm em conta as considerações de segurança durante o processo de criação e criação do aplicativo. As considerações para ajudar a proteger o acesso ao seu aplicativo incluem:

  • Transport Layer Security (TLS). Use o TLS para ajudar a proteger os dados em trânsito. Convém usar o TLS mútuo para seus aplicativos empresariais. Isso será facilitado se você usar malhas de serviço como o Istio no Google Kubernetes Engine. Também é comum que alguns casos de uso criem listas de permissão e negação com base em endereços IP como uma camada adicional de segurança. A segurança de transporte também envolve a proteção de seus serviços contra ataques DDoS e bots.
  • Segurança do aplicativo e do usuário final. A segurança de transporte ajuda a fornecer segurança para dados em trânsito e estabelece confiança. No entanto, é uma prática recomendada adicionar segurança no nível do aplicativo para controlar o acesso ao aplicativo com base no usuário. Os consumidores podem ser outros aplicativos, funcionários, parceiros ou clientes finais da sua empresa. É possível impor a segurança usando chaves de API (para aplicativos para o consumidor), autenticação baseada em certificação e autorização, troca de JSON Web Tokens (JWTs) ou linguagem de marcação para autorização de segurança (SAML).

O cenário de segurança evolui constantemente em uma empresa, dificultando a codificação de constructos de segurança nos seus aplicativos. Produtos de gerenciamento de API, como a Apigee, ajudam a proteger APIs em todas as camadas mencionadas nesta seção.

A segurança da cadeia de suprimentos de software é um desafio a ser resolvido. É importante que você tome precauções. O Software Delivery Shield é uma solução completa totalmente gerenciada que ajuda a melhorar a segurança da cadeia de suprimentos de software em todo o ciclo de vida de desenvolvimento de software. Ele oferece os seguintes serviços, entre outros:

Além disso, vários serviços e funções são preparados para melhorar a segurança da sua cadeia de suprimentos de software.

Para saber mais sobre a segurança da cadeia de suprimentos de software, consulte Segurança da cadeia de suprimentos de software. Para mais informações sobre o Software Delivery Shield, consulte a Visão geral do Software Delivery Shield.

A seguir