Katharina Probst e Justin Becker, gerentes de engenharia na Netflix, recentemente escreveram um artigo no blog técnico da Netflix sobre a manutenção da autonomia dos desenvolvedores em ambientes de desenvolvimento de APIs. O artigo intitulado "Engineering Trade-Offs and the Netflix API Re-Architecture", explora a dificuldade de conciliar o código dos desenvolvedores e a propriedade do processo com múltiplos serviços compartilhados em ambientes de desenvolvimento de APIs.
O crescimento do uso de micro-serviços e a crescente ênfase em utilizar arquiteturas de solução totalmente auto-contidas e auto-gerenciadas (considere como exemplo a popularização do desenvolvimento baseado em containers com ferramentas como o Docker) pode estar na contramão das necessidades dos clientes em acessar distintos serviços de dados sem incorrer em considerável complexidade adicional em suas aplicações. Micro-serviços também apresentam um relacionamento complicado com as melhores práticas da indústria relacionadas e colaboração e reutilização de código, uma vez que eles criam dependências internas do serviço a software externo.
Em seu artigo, Katharina e Justin descrevem que: "... nós estamos trabalhando para conciliar princípios da engenharia de software aparentemente conflitantes: velocidade e propriedade plena versus máxima reutilização de código e consolidação." Como as APIs implicam diretamente em comunicação entre múltiplos serviços, manter a propriedade de utilização de seus dados em uma única equipe pode ser complicado. Se cada micro-serviço tem sua própria API que se comunica diretamente com seus clientes, o próprio micro-serviço tem de lidar com o encargo de tratar as diferentes requisições de seus clientes, prejudicando a noção geral de ser um serviço completamente independente e de máxima produtividade.
Katharina realizou uma palestra na QCon New York 2016 na qual ela descreveu como o Netflix está planejando uma potencial alteração em suas APIs para melhor atender as requisições de diversas aplicações autônomas. A Netflix utiliza apenas uma API que funciona como um serviço de orquestração entre diferentes micro-serviços e suas APIs individuais. Enquanto esta API lida com a complexidade de tratar requisições de clientes em mais de 1000 diferentes dispositivos e endereçá-las a cada serviço necessário, ela também introduz um ponto único de falha na arquitetura. Se a API parar de responder, todos os clientes são afetados ao invés de um pequeno grupo de usuários associados a um serviço. Katharina planeja mitigar o risco de contaminação de serviços em versões futuras da API por meio da utilização de containers. Em sua palestra, ela disse que "no futuro, quando um script apresentar um erro para uma grande classe de problemas...quando um dispositivo ou os scripts para um dispositivo estiverem indisponíveis eles não vão afetar outros dispositivos e não vão afetar a API". Mantendo uma única API de orquestração mas mitigando o risco por meio do isolamento de processos em containers, Katharina acredita que será capaz de manter uma única API que todos os clientes de seus micro-serviços vão utilizar, resultando na plataforma perfeita para compartilhamento de ferramentas e serviços, uma dificuldade notória para diversos micro-serviços.
Enquanto algumas decisões sobre a API, como a utilização de containers para isolamento de scripts foram tomadas inteiramente por Katharina, fica claro que outras decisões ainda permanecem sem uma solução ótima. Por exemplo, um dos principais tópicos no artigo trata de se ter ou não múltiplas APIs de orquestração que dariam aos serviços subjacentes maior controle sobre orquestração ou alterar a API atual para que ela contenha menos lógica e sirva mais estritamente como uma interface para os dados, com a da lógica de tratamento e inclusão dos dados na camada de dados realizada na própria camada lógica específica de cada grupo de serviço. Na primeira abordagem, existe dificuldade em sincronizar todas as diferentes APIs de orquestração, o que cria barreiras para software compartilhado em diferentes grupos de serviços. Na segunda abordagem fica difícil de justificar a adição de latência sem a correspondente adição de funcionalidade, resultando apenas em uma grande distinção e fina granularidade de controle entre serviços. O artigo se encerra sem uma decisão final clara, mas faz alusão a que, independente da solução que se venha adotar, ela será derivada do racional entre diferentes vantagens e desvantagens. Como o número de serviços mais isolados e auto-contidos continua a crescer juntamente com a necessidade de ferramental comum, bibliotecas e conectividade de clientes, pode ser que não exista uma solução perfeita.