Essa tendência irreversível no uso de nuvens públicas e privadas aumentou a importância de ter uma boa base de APIs (Application Programming Interface ou, em português, Interface de Programação de Aplicativos). Afinal, a promessa da nuvem exige que as tarefas sejam automatizadas. Você quer implantar e gerenciar aplicativos rapidamente em vez de esperar dias ou semanas para isso? Então tire os seres humanos do processo e prefira tarefas totalmente automatizadas. É importante ter consciência de que o termo "aplicativo" está muito desgastado nos dias de hoje. Em muitos contextos, o que realmente importa é um serviço de negócios de alto nível que exigirá a organização de muitos sub-aplicativos e de seus componentes subjacentes de infraestrutura. No nível de infraestrutura, isto significará a organização de servidores, rede, armazenamento, segurança, balanceamento de carga e uma série de outros "ingredientes" de TI. Os dias de controle programático de infraestrutura já chegaram e as APIs de infraestrutura são os seus elementos fundamentais.
Quase todo produto tem uma API, mas elas não são todas iguais. Então, como julgar a qualidade e a utilidade das APIs que existem no nível de infraestrutura? Muitas equipes de TI têm mais administradores do que desenvolvedores, portanto poderão não ter todas as habilidades ou experiência para avaliar tão bem quanto gostariam. Temos sorte de estarmos rodeados por alguns dos melhores desenvolvedores do mundo e também já fui exposto a muitas APIs de infraestrutura boas e ruins em mais de 30 anos de carreira. Aqui está o meu checklist:
1- Integrado – O produto deve ter a API integrada. Se eu tiver que instalar uma VM ou um console de gerenciamento externo, a complexidade (e o custo) geralmente aumentam muito rapidamente. Mais configurações, mais atualizações, problemas de recuperação se os consoles de gerenciamento mantiverem o estado (como fazer uma recuperação quando o console e o dispositivo perdem a sincronia?). A não integração imediata é uma má escolha de engenharia, portanto seja cauteloso.
2 – Completa – A API precisa estar 100% completa para o conjunto de recursos do produto. Automatizar 80% da tarefa via API e depois ter que adicionar um script CLI não é uma boa prática.
3 – Atualidade – Integralidade é uma coisa boa, mas se não estiver disponível em até seis meses após cada atualização de software, será um grande problema. Isso reduzirá a flexibilidade e você estará inevitavelmente prejudicado. Para consertar um defeito, será necessário fazer um upgrade – e que todos os APIs estejam no lugar, o que me leva ao próximo ponto.
4 – Compatibilidade – É ótimo ver softwares com novos recursos interessantes, mas nunca interrompa a compatibilidade com versões anteriores de APIs. O ideal é que as APIs sejam versionadas e que a nova versão do software suporte a versão antiga da API. Também é bom ter uma nova versão da API que aproveite os novos recursos.
5 – Documentação – Se o produto não possuir uma boa documentação da API, não se estará tratando com seriedade a habilitação de um caso de uso entre o desenvolvedor e a automação. O outro tipo de documentação que se deve procurar é o "schema". É melhor que o documento tenha um bom exemplo de código, como a saída bem controlada de chamadas API. Boas APIs apesentam uma documentação "schema" de conformidade com os itens 1 e 2 acima.
6 – Comunidade – O compartilhamento de trechos de código e casos de uso, assim como a existência de um fórum para perguntar/responder, aumentam a velocidade de aprendizagem e reduzem o tempo de desenvolvimento e solução de problemas.
7 – Objeto – Orientado a objetos (OO) e de fácil visualização dos principais objetos e ações sem precisar ser expert no produto. Uma vez que alguns dos princípios básicos dos pontos acima estejam no lugar, começa a investigação real. O mapeamento de um caso de uso para uma API envolve a compreensão do modelo de objeto do produto e quais ações são aplicadas a objetos. Como exemplo de armazenamento, quantas chamadas API são necessárias para criar um host, criar/anexar um volume e capturar uma imagem? Se a resposta exceder a quantidade de dedos em suas mãos, não é nada bom. Sempre penso que uma boa e profunda investigação da GUI dos produtos seja uma boa alternativa, devido à complexidade do objeto. Se houver toneladas de páginas da GUI, cliques do mouse e pedaços de informação por toda a interface do usuário, você deverá presumir que o objeto seja complexo e vice-versa.
8 – Linguagem – Esperemos que a API seja REST. O mundo está se movendo em direção aos serviços web/em nuvem e existem toneladas de ferramentas, desenvolvedores e ecossistemas para alavancar. Se o produto tiver um estilo mais antigo e inflado de API (Simple Object Access Protocol – SOAP), ou pior ainda, algum estilo proprietário ou personalizado, o esforço para construir e manter a automação será muito maior.
9 – Utilidades – Muitos administradores poderão não usar a API diretamente, mas usarão uma linguagem de script como PowerShell ou Python para integração com a API. Idealmente, os kits de ferramentas de script vêm do proprietário do produto como caminho de desenvolvimento. O kit de ferramentas de script também precisa ter conformidade com os itens 1 a 6 acima.
10 – Segurança – Quanto tempo se passou desde a última notícia que você leu a respeito de um grande hack? Provavelmente não muito. A segurança não é algo a ser acrescentado mais tarde, ela precisa ser projetada. Apenas como exemplo, no HTTP o HTTPS deverá ser o ÚNICO método de acesso. O que me leva ao ponto final…
11 – Autorização – As APIs devem possuir uma estratégia sólida e fácil de implementar para a autorização e o gerenciamento de sessões. Ela precisa ser segura, mas também fácil de implementar e, de certa forma, leve sob uma perspectiva geral.
Wilson Grava, vice-presidente e gerente geral para América Latina e Caribe da Pure Storage.