Com a adoção do DevOps, as organizações reconheceram que, ao mudar decisões e tarefas para o início do ciclo de vida do desenvolvimento, elas podem identificar e diminuir o risco nos projetos de desenvolvimento. Esse processo é geralmente chamado de "mudança para a esquerda". Como resultado, os desenvolvedores modernos estão sendo solicitados a fazer mais para enviar recursos aos clientes. Elas devem projetar arquiteturas de software escalonáveis, desenvolver códigos seguros e de alto desempenho, configurar a infraestrutura, realizar testes, implantar e monitorar aplicativos e muito mais. Embora essa abordagem resulte em muitos benefícios, ela também dá aos desenvolvedores menos tempo para se concentrarem na programação, o que pode resultar em efeitos indesejados na qualidade do software ou atrasar o lançamento de novos recursos.
Da mesma forma que os engenheiros de DevOps se concentram na otimização da entrega de software para clientes externos, como engenheiros de plataforma, seu foco é criar uma plataforma que ofereça experiências consistentes e perfeitas aos clientes internos (ou seja, os desenvolvedores). Como é a criação de uma plataforma interna? Sua tarefa diária precisa envolver a criação de experiências padronizadas para seus desenvolvedores que permitam autonomia. Ao fazer isso, você diminui a sobrecarga cognitiva para seus clientes internos ao desenvolver e implantar novos serviços. Uma plataforma interna de desenvolvimento incorpora determinadas decisões, padrões e processos para criar caminhos dourados para os desenvolvedores. Isso permite que seus desenvolvedores se concentrem na programação, o que permite que eles criem melhores experiências de software para os clientes. Dito de outra forma, além de mudar para a esquerda, as organizações também devem "diminuir" e colocar mais responsabilidade na plataforma:
Ao desenvolver APIs para que seus desenvolvedores aproveitem ao máximo suas plataformas, você precisa:
Um ótimo aplicativo é inteligente e consistente na entrega de produtos e serviços. Ela oculta a complexidade e torna sua operação simples e agradável de usar. O objetivo final deve ser sempre proporcionar uma ótima experiência ao usuário, e as organizações que criam produtos de sucesso sempre começam de fora para dentro, tendo em mente os usuários. A oferta de uma ótima experiência é alcançada capacitando os desenvolvedores a criar aplicativos inspiradores e, para isso, é essencial fornecer a eles ótimas APIs. Ótimas APIs abstraem as complexidades da organização, permitindo que os desenvolvedores se concentrem na criação da experiência do usuário. No entanto, APIs excelentes não aparecem do nada. Essas organizações também tratam as APIs como produtos digitais, dedicando equipes inteiras à criação e ao gerenciamento como um recurso fundamental das plataformas.
A plataforma que um desenvolvedor utiliza para criar produtos digitais também precisa ser tratada como um produto e, dessa forma, as equipes de engenharia de plataforma também devem ter uma abordagem externa com os usuários (os desenvolvedores) para entender os requisitos deles e criar uma experiência agradável para eles. Como engenheiros de plataforma, é sua responsabilidade criar, desenvolver e unificar modelos e ferramentas internos que seus desenvolvedores usarão ao desenvolver software, seja para desenvolver aplicativos front-end, serviços de back-end ou produzir e consumir APIs. O papel da sua equipe é estabelecer como o software que sua organização está criando deve ser testado, protegido, implantado e gerenciado. Eliminar os silos permite uma melhor criação de APIs.
Assim como em outros aspectos do desenvolvimento de software, sua equipe deve desencorajar os desenvolvedores a recriar individualmente elementos de arquiteturas de API que sejam preocupações transversais. Em vez disso, ofereça um conjunto de ferramentas e opções de configuração simples que eles podem usar prontamente. Alguns aspectos do gerenciamento de APIs que são mais bem administrados pela sua plataforma incluem, entre outros:
A Apigee é uma plataforma de gerenciamento de APIs que oferece às equipes de plataforma e aos clientes internos um conjunto de recursos para criar, governar e operar APIs com mais eficiência:
A Apigee ajuda os produtores de APIs a criar e gerenciar as APIs que expõem a lógica de negócios deles, fornecendo camadas adicionais de segurança, descoberta e observabilidade para os desenvolvedores. As equipes de produtos podem agrupar e publicar as APIs como conjuntos flexíveis de “produtos”, com comportamento de consumo variável. A Apigee também ajuda os consumidores de API a saber facilmente quais produtos de API estão disponíveis, consultar documentação e fazer a integração rápida para começar a desenvolver aplicativos com o mínimo de atrito. Agora, com a ajuda da IA generativa, a Apigee também está reimaginando a forma como as APIs são desenvolvidas, facilitando o gerenciamento da comunicação entre os sistemas de desenvolvedores iniciantes e experientes.
O processo de gerenciamento de APIs na Apigee começa com a criação de proxies de API. Um proxy de API expõe a interface que os desenvolvedores usam para acessar os serviços de back-end. Em vez de consumir esses serviços diretamente, eles acessam um proxy de API da Apigee criado pelo produtor. Com um proxy, é possível separar o back-end da API real, o que oferece ao cliente uma experiência mais confiável. Isso permite que você atualize e faça alterações no back-end sem afetar o cliente. As equipes de API podem aproveitar os recursos fornecidos pelo proxy para proteger e controlar o comportamento de suas APIs. Para que um programa de API seja dimensionado com sucesso à medida que o número de equipes de produção e consumo cresce, a plataforma precisa permitir caminhos dourados por meio de pipelines de automação contínuos e funcionalidade reutilizável.
Digamos que sua empresa queira criar novas APIs que possam ser monetizadas para gerar mais receita. Sua equipe se reúne com os desenvolvedores para elaborar uma estratégia abrangente sobre como essas novas APIs devem ser criadas. O trabalho de sua equipe agora é pegar esses requisitos e padronizá-los na forma de modelos de API opinativos, contendo políticas comuns, controles de roteamento de tráfego e convenções de tratamento de erros. Dependendo do caso de uso, pode haver conjuntos de modelos para cada caso de uso. Um caso de uso comum seria fornecer políticas de armazenamento em cache ou transformação para back-ends legados em execução em ambientes locais. O repositório Apigee-samples é um ótimo lugar para começar, e nosso repositório DevRel também contém exemplos de modelos de proxy para referência. Além dos modelos de política, as equipes de plataforma também podem padronizar os pipelines que os desenvolvedores vão consumir para criar e implantar proxies. A Apigee oferece APIs e ferramentas de gerenciamento que podem ser usadas para criar pipelines de CI/CD compatíveis com esses caminhos de ouro. Publicamos implementações de referência que você pode usar como ponto de partida.
Um pipeline de proxy da API MVP do código-fonte pode ser semelhante a este:
Além disso, o pipeline pode registrar a API em um catálogo interno, como o hub de APIs da Apigee. O hub de API é uma ferramenta que ajuda as organizações a documentar, encontrar e publicar informações sobre as APIs. O registro integrado ao hub contém informações detalhadas sobre cada versão de uma API durante o ciclo de vida dela, incluindo especificações associadas, implantações atuais, informações de propriedade e contato, dependências e muito mais. Além das propriedades integradas, os clientes podem definir as próprias taxonomias que os usuários podem pesquisar e filtrar. Para melhorar ainda mais a qualidade e a consistência, o hub de API também oferece visões gerais que permitem aos desenvolvedores entender melhor como os projetos de API atendem aos padrões esperados. O registro do hub de API pode ser sincronizado com portais de desenvolvedores internos, como o Backstage ou outras ferramentas internas da plataforma para desenvolvedores.
Por fim, para consumidores externos, o pipeline pode publicar produtos de API em um portal de API voltado para o público, além de documentação adicional e guias do usuário, todos com estilo e marca personalizados.
Ao criar APIs em escala, uma prática recomendada é reutilizar políticas comuns para aumentar a velocidade de desenvolvimento e reduzir o tempo de entrega. Na Apigee, os fluxos compartilhados permitem aplicar a padronização e a consistência em todas as APIs. Com os fluxos compartilhados, é possível combinar políticas e recursos e compartilhá-los entre vários proxies de API usando uma política Flow callout ou hooks de fluxo. Os fluxos compartilhados geralmente são desenvolvidos separadamente dos proxies de API, geralmente pela equipe da plataforma ou por especialistas no assunto responsáveis por determinadas áreas. Por exemplo, é possível desenvolver um fluxo compartilhado que capture um conjunto padrão de campos de solicitação e resposta e os grave no Cloud Logging. Outro pode ser um fluxo de tratamento de erros que gera mensagens de erro e códigos padronizados ou um fluxo de autenticação que se integra a um provedor de identidade de terceiros. O desenvolvimento de fluxo compartilhado pode ser automatizado, testado e implantado usando as mesmas ferramentas e conceitos que os proxies de API. Veja outros exemplos de fluxos compartilhados comuns.
O GitOps ficou conhecido durante o surgimento do DevOps. Esse framework aproveita as práticas recomendadas, como usar o controle de versões via Git, solicitações de envio, pipelines de CI/CD, automação e políticas de conformidade. Confira este blog em detalhes sobre as práticas recomendadas para o envio de APIs. Essas práticas podem ser transformadas em caminhos de ouro para os desenvolvedores. Por exemplo, um desenvolvedor pode projetar uma API usando a Duet AI para criar uma especificação OpenAPI antes de enviá-la para uma ramificação de recurso, o que acionaria uma solicitação de envio. Depois que a solicitação de envio é aprovada e mesclada, o pipeline de CI/CD é iniciado automaticamente. O processo é repetido para cada ambiente. Na Apigee, as equipes de plataforma podem criar organizações e ambientes separados para implantar e testar proxies à medida que avançam no ciclo de vida de desenvolvimento. Com uma estratégia de GitOps, cada ramificação do repositório do Git pode ser mapeada para um ambiente da Apigee.
Os clientes que usam o modelo de pagamento por utilização da Apigee podem escolher diferentes tipos de ambiente com recursos variados, e eles podem criar diversos tipos de ambiente para diferentes casos de uso.
Ao hospedar seu proxy e código de fluxo compartilhado em repositórios de origem e usar o GitOps, você pode criar caminhos dourados para seus desenvolvedores de API, permitindo que eles se concentrem na criação de ótimas APIs e na implementação da lógica de negócios subjacente. Para facilitar ainda mais, os desenvolvedores também podem desenvolver e testar localmente usando o plug-in do Cloud Code para VS Code.
Uma maior colaboração entre o desenvolvedor e a equipe da plataforma libera o desenvolvedor do fardo de fazer tudo por conta própria. Ao reduzir a complexidade, o desenvolvedor pode se concentrar no que faz de melhor, o que resulta em uma experiência melhor para o cliente. Tratar suas APIs e plataformas como produtos da sua organização aumenta a autonomia, a velocidade, a qualidade e a inovação. Ao usar as estratégias descritas acima, você pode reduzir a carga dos seus desenvolvedores e ajudá-los a criar APIs melhores. Tudo pronto para começar? É possível se inscrever e começar a criar no seu próprio sandbox gratuito. Quer informações mais detalhadas sobre preços? Confira os novos preços da Apigee e use nossos recursos para começar a incorporar o gerenciamento de APIs à sua plataforma de desenvolvedores.