A economia de API chegou, e os desafios que vêm com ela também. As APIs agora estão em todos os lugares, incorporadas em tudo, como aplicativos móveis e dispositivos IoT, e as expectativas em torno do que elas podem fazer estão aumentando. No entanto, as ferramentas e plataformas destinadas a domar essa bagunça geralmente não atendem.
Tive o prazer de participar do recente Nordic APIs Platform Summit em Estocolmo, Suécia, no início deste mês, e ficou claro que, embora os benefícios das APIs sejam inegáveis, as dores associadas são muito reais. Eu queria compartilhar algumas das minhas principais conclusões na esperança de que nosso foco coletivo leve a soluções.
Não vamos jogar o bebê fora junto com as caldeiras oceânicas
Agora, estou vindo da perspectiva de um VP de engenharia em uma startup de tecnologia onde nosso novo foco está principalmente no lado do desenvolvimento do mundo da API. Mas durante meu tempo na conferência, ficou claro que a indústria está inundada com promessas de soluções de gerenciamento de API monolíticas "tamanho único". Nos últimos dois anos, muitos têm promovido suas ofertas como "caldeiras oceânicas", alegando resolver tudo de uma só vez.
Você provavelmente pode adivinhar o que vem a seguir, porque todos nós sabemos que o oceano não pode ser fervido. A tensão resultante entre o que está sendo prometido e o que está realmente sendo entregue é palpável. Os desenvolvedores estão se tornando cada vez mais vocais sobre a lacuna entre essas promessas e a realidade. Mas isso não significa que devemos jogar todos esses esforços fora; o que precisamos é de uma mudança de mentalidade. Estamos à beira de uma nova fronteira que exige algo diferente, algo matizado.
Essa nova mentalidade, que surgiu no Platform Summit, é um movimento em direção ao APIOps e à alavancagem de plataformas componíveis que não visam fazer tudo. Em vez disso, essas plataformas devem se concentrar em fazer as coisas principais corretamente.
Uma mudança de ferramentas especializadas para monolíticas parece acontecer a cada poucos anos, mas desta vez vem com uma reviravolta centrada no desenvolvedor. As empresas podem selecionar (também conhecidas como desenvolvedores podem adotar) as melhores ferramentas para funções-chave que tenham a flexibilidade e a componibilidade para integrar a experiência de plataforma ideal, fornecendo o processo e a visibilidade exigidos pelas empresas hoje sem as batalhas de adoção. Isso requer uma abordagem muito mais centrada no desenvolvedor para o desenvolvimento de API e estratégia de plataforma.
As plataformas de desenvolvedores servem como a espinha dorsal do paradigma da engenharia de plataforma e não servem apenas para fornecer ferramentas e serviços; elas servem para motivar e capacitar os desenvolvedores a produzir seu melhor trabalho.
Ainda estamos falando sobre a experiência do desenvolvedor
Isso me leva à minha próxima lição da conferência. Em meio ao caos de APIs proliferando a cada momento, uma coisa é clara: a experiência do desenvolvedor (DX) ainda é importante. As melhores ferramentas neste espaço não são apenas sobre recursos chamativos. Elas são sobre permitir que os desenvolvedores façam o trabalho que desejam e precisam fazer sem desacelerar o processo. E essa necessidade de uma boa experiência não é perdida pelos desenvolvedores.
Para traduzir isso de forma tangível — coisas como controle de versão de API e gerenciamento de ciclo de vida precisam ser incorporadas desde o primeiro dia, não adicionadas depois. Práticas consistentes de testes completos e segurança devem ser fáceis e acessíveis, não incômodas ou confusas. E a documentação, frequentemente negligenciada, precisa ser um cidadão de primeira classe desde o início.
Os desenvolvedores querem soluções que simplifiquem seus desafios diários, não os compliquem. As melhores ferramentas são aquelas que ajudam os desenvolvedores a iterar mais fácil e rapidamente por seus loops de desenvolvimento sem insultar sua inteligência (o que é uma arte e tanto quando você pensa sobre isso). A lição é simples: ferramentas que realmente entregam DX vencerão o dia. No centro da experiência do desenvolvedor estão os loops de desenvolvimento interno e externo. O loop de desenvolvimento interno é o ciclo de atividades que um desenvolvedor realiza localmente enquanto trabalha em um recurso ou correção de bug. Em contraste, o loop de desenvolvimento externo abrange o ciclo de vida de desenvolvimento mais amplo. A chave para aumentar a velocidade do desenvolvedor está na otimização de seus loops de desenvolvimento.
Precisamos encontrar maneiras de minimizar o "imposto" imposto pelas várias etapas do fluxo de trabalho de desenvolvimento, particularmente complicado nos microsserviços e ambientes nativos de nuvem de hoje. A combinação certa de abordagem de plataforma e experiência do desenvolvedor pode fazer isso.
Algumas das ferramentas mencionadas na conferência que oferecem soluções para uma melhor experiência do desenvolvedor foram:
Ferramentas como o Specmatic oferecem uma maneira de testar conformidade, compatibilidade e desvio no momento do design, abordando problemas antecipadamente. Linguagens como TypeSpec elevam a documentação da API ao status de primeira classe, facilitando para os desenvolvedores manter a consistência e a clareza.
Claro, seria negligente não mencionar ferramentas como o Blackbird como inestimáveis na otimização dos ciclos internos e externos do desenvolvedor. Essas foram apenas algumas das ferramentas que fornecem a capacidade de composição que mencionei anteriormente e que se adaptam ao seu fluxo de trabalho existente, em vez de forçar você a se adaptar ao delas.
Há frutos fáceis de colher: precisamos acertar na segurança
Embora os desafios sejam significativos, ainda há oportunidades para vitórias rápidas se você estiver procurando nos lugares certos. Depois de ouvir todas as sessões, é evidente que boas práticas de segurança se destacam entre as oportunidades mais acessíveis para melhoria, não importa onde você esteja preso no ciclo de vida da API.
Padrões testados e comprovados para evitar armadilhas comuns de autenticação e autorização podem reduzir muito os riscos de segurança. Além disso, realizar regularmente avaliações de vulnerabilidade e aplicar criptografia a dados confidenciais em trânsito e em repouso pode proteger ainda mais as APIs de possíveis explorações.
E, claro, não podemos esquecer a popular abordagem de confiança zero que está enraizada no princípio de tratar usuários, sistemas e tráfego de rede como fundamentalmente não confiáveis, mesmo que estejam dentro do perímetro de segurança estabelecido por um firewall. Ou muitos estão buscando deslocar a segurança para a esquerda para garantir que seja mais uma prioridade no início do SDLC.
O que quer que você esteja fazendo para garantir que a segurança seja uma prioridade, acertar é uma das coisas mais fáceis que os desenvolvedores podem alcançar, e muitos de nós ainda estamos falhando. E com o aumento de violações e invasores (aumento de 400% somente nos últimos seis meses, de acordo com a Salt Security), não podemos mais ignorar o reforço de nossas medidas de segurança.
O futuro é artificial e inseguro
A IA foi, sem surpresa, o elefante em todas as salas da cúpula, como tem sido em todas as conferências, painéis e assuntos de artigos no ano passado. Por mais que a indústria esteja falando sobre APIs, a IA está influenciando tudo, desde como construímos APIs até como nossos consumidores interagem com elas. O desafio para os designers de API não é apenas sobre como usar a IA, mas também sobre criar APIs e plataformas que possam se adaptar a como outros estão usando a IA em seus sistemas.
Claro, com mais APIs vêm mais dispersão e mais deriva, fatores que expandem muito a superfície para ataques de segurança. À medida que desenvolvedores e empresas tentam navegar nessa complexidade crescente, a questão de quem e no que confiar se torna mais urgente. A resposta infeliz é simples: ninguém e nada. Arquiteturas de confiança zero e práticas rigorosas de validação estão se tornando mais relevantes.
A boa notícia é que as soluções para combater essa expansão são cada vez mais abundantes. Não importa se você chama isso de "governança", "padronização" ou "ter uma estratégia de plataforma", essas soluções só se tornarão mais importantes para a economia de APIs à medida que as APIs proliferam e nossa necessidade por arquiteturas de microsserviços flexíveis e componíveis aumenta.
No final, foi uma ótima chance de se conectar com outros colegas com mentalidade de API e líderes de tecnologia no summit. A nova fronteira é promissora, desde que você esteja armado com as ferramentas, abordagens e mentalidade certas.
