Microsserviços, APIs e inovações: o poder das APIs

Olá pessoal!



Hoje, gostaríamos de oferecer a você uma tradução de um artigo de programação do famoso Mike Amundsen , o arquiteto principal da API Academy. Neste texto comparativamente curto, Mike explica de maneira inteligente por que você precisa prestar atenção especial ao desenvolvimento da API e como as APIs são feitas corretamente.

Durante meu tempo como professor na API Academy, tive a oportunidade de viajar pelo mundo conhecendo pessoas incríveis. Eles trabalham em projetos impressionantes em várias empresas - desde jovens startups até empresas globais estabelecidas. Incrivelmente, mas onde quer que eu estivesse e com quem conversei, muitas idéias, truques e impressões comuns surgiram em nossas conversas. Os três mais comuns são microsserviços, APIs e uma cultura de inovação. Todos os três estão sendo apresentados para acelerar a transformação digital da organização.

Este artigo é o segundo de uma série de três publicações. Aqui, falarei sobre o que ensinamos em nossa academia de APIs no contexto dessas três tendências poderosas e também descreverei alguns truques que ajudarão sua empresa a passar de grandes palavras para conversões reais. Em um artigo anterior, prestei atenção especial à importância dos microsserviços e concentrei-me em três coisas que você pode fazer hoje: 1) a transição para a entrega contínua, 2) o fornecimento de implantações preparadas e 3) reduzir a fila "em funcionamento" para reduzir o tempo antes do produto chegar o mercado. Esses três hábitos essenciais ajudarão sua organização a tirar o máximo proveito dos benefícios dos microsserviços.

APIs fornecem entrega multicanal

Muitas empresas usam microsserviços, tentando encapsular os principais recursos de sua organização de forma a garantir sua escalabilidade e confiabilidade. Os microsserviços correspondem a importantes elementos funcionais do componente de TI da sua empresa. Mas isso é apenas metade da batalha. Também é necessário descobrir como oferecer essas oportunidades, para que, com a ajuda deles, seja conveniente resolver os desafios atuais que seus negócios enfrentam. É aqui que a API entra em jogo.

APIs - interfaces de programação de aplicativos - desempenham o mesmo papel para uma máquina que uma interface gráfica - para os usuários dos sistemas de informação da sua empresa. Freqüentemente, as APIs são usadas para misturar diferentes recursos em uma solução consistente e acessível. Por exemplo, sua empresa pode usar serviços para processar transações relacionadas a clientes, contas e vendas. Cada um desses serviços foi cuidadosamente projetado, programado, testado, após o qual foi lançado e incorporado à infraestrutura da sua empresa; O serviço fornece funcionalidade crítica para o seu negócio. Depois que você precisar criar uma nova solução para apresentar aos usuários o curso das coisas - e essa solução deve funcionar em uma variedade de dispositivos e plataformas. Então, estamos começando a usar a API em capacidade total.

Uma única API, aprimorada para soluções - por exemplo, uma API para familiarizar os usuários com o sistema - pode ser projetada para que as interações e fluxos de tarefas mais importantes que são críticos no estágio dessa familiarização venham à tona. Aqui, precisamos de uma API que permita combinar vários elementos funcionais relacionados a clientes, contas e vendas em interfaces de usuário seguras, poderosas e acessíveis para uma ampla variedade de públicos-alvo na sua empresa. Por exemplo, o pessoal de vendas pode efetuar login a partir de um navegador, administradores de escritório de aplicativos para PC e clientes em potencial de smartphones e tablets.

Podemos dizer que a API é um tipo de "cola" que mantém os elementos do programa juntos, uma camada intermediária através da qual seus serviços internos e consumidores externos de serviços interagem. A API é a ferramenta para distribuir as principais funcionalidades de maneira que os consumidores de serviços possam usá-las, cuja tarefa é criar mecanismos importantes para interagir com o usuário em uma variedade de plataformas de hardware. Esses consumidores podem incluir outras equipes que trabalham em seu escritório, colegas com quem você se comunica remotamente, principais parceiros de negócios ou até funcionários remotos envolvidos no desenvolvimento ou no design do cliente.

Design Thinking e API

A maioria das empresas sabe o quanto é importante dedicar tempo ao desenvolvimento de uma interface do usuário para seus aplicativos. Porque é sabido que o bom design é apreciado pelos usuários, aumenta a fidelidade à marca e permite promover um novo negócio. Ao mesmo tempo, o design de interface mal projetado pode incomodar os clientes, prejudicar a marca, reduzir a receita e selecionar oportunidades. O mesmo vale para o design da API.

Se a API for mal executada, será difícil para os desenvolvedores entendê-la, por isso eles podem introduzir erros no sistema e provocar despesas desnecessárias para corrigir bugs e modificar a infraestrutura. No entanto, se a API funcionou bem, é mais fácil para o funcionário trabalhar efetivamente com ela. O tempo necessário para criar uma solução estável é reduzido, a equipe ainda recebe um incentivo para emitir soluções novas e inovadoras que ajudariam clientes e colegas. O design da API é uma área de trabalho tão importante que Werner Vogels, diretor de tecnologia da Amazon, até disse:

Reconhecemos imediatamente que projetar uma API é uma tarefa muito importante, pois teremos apenas uma tentativa de resolvê-la corretamente.

São APIs de alta qualidade que ajudam a atrair parceiros para seu ecossistema digital e simplificam as transformações corporativas internas de seus negócios. A capacidade de gastar tempo para fazer tudo certo e, a longo prazo, é uma habilidade importante que identificamos apenas nas empresas que aprenderam como utilizar plenamente suas APIs.

Dicas essenciais de design de API

É muito importante corrigir a API - e há muitos motivos. Após o lançamento, é impossível reverter a API. Quando os clientes e as principais estruturas de negócios dependem da sua API, alterar a dependência pode danificar outros elementos do sistema, interromper funcionalidades importantes e zerar seus investimentos e tempo gasto. Ao implementar o programa API, você precisa ter em mente outras coisas importantes. Vou mencionar apenas alguns.

API canônica não existe

É um erro tentar "antecipadamente" escolher um design de API canônico para toda a sua empresa. Apenas tentando implementar alguns objetos e modelos de dados em toda a empresa, ou seja, tentando criar uma única API que levaria em consideração todos os aspectos da sua organização sem exceção, agora e no futuro - provavelmente esse é um beco sem saída. É muito melhor fornecer recomendações aos desenvolvedores e indicar restrições que os ajudarão a evitar erros, revelar e aplicar criativamente o conhecimento do domínio para criar APIs incríveis que serão atraentes para colegas e parceiros.

Processo de implementação: eliminando todos os desnecessários

Como a API é apenas uma interface, não funcional como tal, você precisa ser capaz de projetar, implementar, testar e implantar a API em questão de dias e semanas, mas não em meses. Sabemos como as empresas estão tentando reduzir os riscos de criar uma API, garantindo que a API seja conveniente para testar com antecedência, automatizar o processo de liberação, para que as próprias APIs sejam menos dispendiosas e mais fáceis de compor.

Foco na interação, não na integração

Outro aspecto importante com o qual as empresas de sucesso podem lidar é a capacidade de ensinar às equipes de desenvolvimento a integração na API a capacidade de interagir com outros elementos já em fase de design. Essas organizações explicam como trabalhar com suas APIs; portanto, essas APIs não são apenas fáceis de entender, mas também facilmente vinculadas a outras APIs dessa empresa. Focar na interação ampla é mais importante do que projetar uma integração estreita e estreita.

Três coisas que você pode fazer hoje

Esse trabalho, como qualquer mudança importante, leva tempo. No entanto, não demorará muito para esperar pelo sucesso. Vou falar sobre três medidas que tive que observar em várias empresas, que você pode tomar hoje.

Adote sua própria prática de API

Um componente essencial do sucesso a longo prazo do seu programa de API é desenvolver práticas de design de API específicas da tecnologia. Certifique-se de que esse programa não dependa inteiramente da última moda em programação, usando bibliotecas ou plataformas. Para isso, é mais conveniente contar com o paradigma "primeiro passo - API".

"A primeira coisa é a API" significa que primeiro projetamos a API e só então pensamos nos detalhes de sua implementação. Em princípio, o componente de negócios é o mesmo, independentemente da tecnologia usada para implementar a API: seja SOAP, CRUD, REST, gRPC, GraphQL ou qualquer outra coisa popular. De fato, um programa bem projetado provavelmente permitirá formular recomendações relevantes para diferentes pilhas de tecnologia, respectivamente, ajudando sua equipe a avaliar possíveis economias e manter a consistência das decisões nas versões subseqüentes das plataformas.

Garantimos baixos riscos ao criar uma API

Depois de projetar a API com alta qualidade, é hora de transformá-la em realidade. Ao mesmo tempo, recomendo começar com um esboço e depois passar para o padrão de protótipo e montagem.

APIs de estrutura de tópicos são precisamente "esboços". Pequenos "desenhos" aproximados que ajudam a dar uma impressão de como essa API pode se transformar em "gosto e cor" da posição de um desenvolvedor. Um esboço da API deve ser feito em algumas horas, não em dias. Além disso, com base nisso, deve-se obter um projeto que possa ser mostrado aos colegas e partes interessadas, para que a primeira rodada de discussão e as primeiras modificações não custem quase nenhum custo. Eu gosto de usar o modelo da API do Apiary para isso. Ele usa uma linguagem de marcação simples que permite simular um servidor API funcionando em minutos. Uma ferramenta específica não é tão importante, a prática é importante. Os tópicos ajudam a fazer pesquisas baratas e só então começam a preparar uma API completa.

Percebi que, ao prototipar, ferramentas como Swagger / OpenAPI são populares. Protótipos são modelos muito mais elaborados do seu produto final. Eles são semelhantes ao cenário do filme. Se você não olhar de perto, verá uma cena praticamente real! A equipe deve ser capaz de preparar um protótipo detalhado em apenas alguns dias. Esse protótipo deve se conectar livremente a instrumentos de teste, serviços de virtualização e outros elementos da plataforma, para que você possa observar diretamente como ele interage com seu sistema. Protótipos são necessários para testá-los. Eles são sua última linha de defesa antes que você tenha que gastar dinheiro criando uma API de trabalho real.

Aqui a fase de montagem está concluída. Em seguida, devemos formular um plano de trabalho, estabelecer prazos e começar a transformar o protótipo em um produto. Precisávamos de um esboço e um protótipo para descobrir os detalhes, identificar bugs etc. O processo de compilação em si não é tão interessante. Você só precisa mostrar o resultado final todos os dias, implementar passo a passo a API até que o trabalho esteja pronto. Muitas empresas se esforçam para criar API no máximo por 90 dias.

API de gerenciamento de três baleias

Por fim, se você considerar a situação de maneira mais ampla do que no nível de design e implementação de uma API específica, precisará aderir a um programa viável para trabalhar com a API em sua organização e aplicar recomendações gerais para o desenvolvimento de APIs que serão conhecidas por todas as equipes. Uma regulamentação clara permite que você controle o desenvolvimento da API em toda a empresa, sem precisar de supervisão excessiva dos detalhes da implementação.
Eric Wilde, meu colega na API Academy, enfatiza a importância de "gerenciar o cenário de suas APIs", ou seja, regular três elementos principais de um programa de API: protocolos, formatos e terminologia.

A regulamentação de protocolo é uma indicação clara de quais protocolos em nível de aplicativo uma equipe de API deve oferecer suporte ao preparar novos lançamentos. A maioria das empresas acredita que todas as novas APIs devem suportar HTTP. Alguns também indicam outros protocolos opcionais, como MQTT, Thrift e outros protocolos binários. Aqui, é mais importante informar todas as equipes com antecedência: "Se você deseja garantir a interoperabilidade de suas APIs no futuro, deve usar esses protocolos". Para implementar essa regra, é aconselhável usar um pipeline de entrega contínua.

A regulamentação de formatos significa que você precisa concordar em quais formatos os dados serão enviados entre os serviços. Quase todos os navegadores esperam uma resposta no formato HTML - assim, no nível da sua API, você precisa decidir em qual formato ele irá interagir com todo o ecossistema. A maioria das empresas prefere formatos simples, como JSON, XML ou CSV, mas seus modelos de mensagens não possuem metadados principais, em particular nomes de objetos, links e formulários de entrada - e são necessários para interações de longo prazo. Por outro lado, também conheço empresas que usam formatos mais avançados, por exemplo, HAL, Siren e Collection + JSON para APIs baseadas em HTTP. Para interações binárias entre serviços, muitas organizações usam protobuf e formatos semelhantes como base. Independentemente de qual formato você escolher, é importante verificá-lo em sua linha de montagem, certificando-se de que apenas APIs que cumpram totalmente os regulamentos entrem em produção.

O terceiro kit de gerenciamento de API é terminologia. Nesse caso, estamos falando sobre o controle sobre os nomes dos pontos de dados e identificadores de ação usados ​​ao trocar mensagens entre serviços. Seguindo a terminologia, a organização pode não ter dúvidas de que os novos serviços serão normalmente aceitos pelos existentes. Lembrando a “linguagem comum” proposta por Eric Evans para o DDD (Projeto Orientado a Assuntos), observo que a terminologia que você escolhe é necessária para falar sobre a operação comercial mais crítica. Deve ser difícil produzir um serviço em produção que use nomes “novos” para campos de dados e identificadores de ação. Pelo contrário, os elementos da linha de montagem devem ser verificados quanto à conformidade com a terminologia geral aceita em toda a empresa, e as APIs que abandonam essa terminologia não devem entrar em produção.

Após aprender esses princípios: “Primeiro de tudo - API”, “conjunto de protótipos de esboço” e “kit de controle de três APIs”, sua equipe poderá usar suas APIs com capacidade total, sem arriscar sua estabilidade durante a execução.