O uso expressivo e expansivo de APIs está contribuindo para o surgimento da arquitetura headless e fornecendo ao GraphQL um lugar de destaque nessa arquitetura de aplicações neomoderna.
Por mais de duas décadas, mudanças significativas de paradigma nas arquiteturas de aplicativos impactaram diretamente a evolução da entrega de aplicativos. Historicamente, arquiteturas de aplicativos destinadas a dominar e influenciar nosso mercado crescem e começam a moldar o mercado a cada cinco anos e se tornam dominantes cerca de cinco anos depois disso, o que, por sua vez, impulsiona mudanças no mercado de entrega de aplicativos.
Os microsserviços (nativos da nuvem) ganharam participação no mercado em 2015, mas foi somente em 2020 que a malha de serviços e o controle de entrada surgiram, impulsionando a direção do cenário de entrega de aplicativos. Agora estamos vendo os primeiros indícios de uma nova arquitetura — headless — surgindo e que substituirá os microsserviços como a força motriz na entrega de aplicativos.
Com base em tendências históricas, a arquitetura headless alcançará a participação do mercado até 2025 e começará a impulsionar mudanças no mercado de entrega de aplicativos. A confiabilidade desse ciclo, combinada com a crescente atividade e interesse no mercado relacionado a APIs e tecnologia gráfica, prevê um impacto significativo na entrega de aplicativos até o ano de 2030.
Existem diversas forças externas impulsionando duas tendências tecnológicas a convergirem, o que resultará na próxima grande mudança na entrega de aplicativos: Design API-first e a democratização de dados .
O impulso para digitalizar os negócios se manifesta como ' serviços digitais ' fornecidos por uma ' empresa digital '. Serviços digitais são construções empresariais efêmeras, compostas de aplicativos, entrega de aplicativos, segurança de aplicativos e dados, integrados, orquestrados e operados por meio do uso de APIs. Oitenta e dois por cento das organizações hoje fornecem serviços digitais para consumidores internos e externos (SOAS 2022 ).
Simultaneamente, a adoção de microsserviços, que se comunicam principalmente por meio de APIs, continua a aumentar. De acordo com nossa própria pesquisa , estimamos que “o número de APIs públicas e privadas hoje está se aproximando de 200 milhões, e em 2031 esse número pode chegar a bilhões”.
Tendência: O resultado é uma mudança em direção às APIs em uma magnitude que causará disrupção no mercado de entrega de aplicativos maduros, da mesma forma que os dispositivos móveis e os microsserviços causaram disrupção no mercado de entrega de aplicativos entre 2010 e 2020.
|
|
A descentralização é o resultado da atividade digital distribuída decorrente do trabalho remoto, da adoção em massa da IoT e das preocupações com a privacidade dos dados. A descentralização geralmente está vinculada a tecnologias Web3, como blockchain e computação de ponta, principalmente quando aplicada à IoT industrial. O resultado da descentralização, no entanto, é o que realmente impulsiona a disrupção. Tanto os dados quanto os aplicativos são "descentralizados", o que introduz os desafios de desempenho e segurança esperados de qualquer sistema distribuído. Isso inclui 77% das organizações que buscam implantar processamento de dados e cargas de trabalho de front-end digital na borda ( SOAS 2022 ).
Tendência: A descentralização tem consequências que vão além dos aplicativos distribuídos, pois também incorpora a capacidade de distribuir dados. As abordagens tradicionais relegam os dados a uma camada protegida, atrás dos aplicativos. A descentralização está forçando uma nova abordagem na qual os dados são expostos diretamente por meio de APIs, sem a necessidade de um intermediário (aplicativo). Essa mudança elimina a abordagem baseada em camadas para a arquitetura de aplicativos e fornece uma rota direta para dados para parceiros externos, desenvolvedores terceirizados e consumidores. O início dessa democratização de cargas de trabalho dentro da arquitetura de aplicativos pode ser visto nas arquiteturas de microsserviços. Também vemos o valor comercial existente na democratização de dados em modelos de negócios que dependem de inversão; ou seja, liberando dados por meio de APIs para criar valor para parceiros e desenvolvedores terceirizados.
Também vemos o valor comercial existente na democratização de dados em modelos de negócios que dependem de inversão, ou seja, liberando dados por meio de APIs para criar valor para parceiros e desenvolvedores terceirizados.
A digitalização está gerando demanda por mais talentos de engenharia do que os existentes no mercado. Isso faz com que as organizações não consigam acessar os vastos estoques de dados gerados por um negócio digital. Os talentos existentes estão sobrecarregados e muitas vezes não conseguem se desenvolver tão rapidamente quanto as demandas dos negócios.
Essa lacuna entre oferta e demanda está gerando um aumento nas soluções de baixo código/sem código para permitir que um conjunto mais amplo de usuários desenvolva soluções e serviços. Pesquisas indicam que 75% das empresas adotarão uma “mistura de low-code/no-code e inovação convencional”.
Tendência: Soluções de baixo código/sem código dependem do acesso à lógica de negócios e aos dados, ambos amplamente disponibilizados pela democratização dos dados e pelo design que prioriza a API. A necessidade dessas soluções atua como um acelerador para a maturação das tendências de dados e API.
A linguagem usada no mercado relacionado a APIs — roteadores, gateways, middleware — é semelhante à linguagem usada antes das mudanças anteriores no mercado impulsionadas por microsserviços, dispositivos móveis e mudanças arquitetônicas. A atividade, a terminologia e a taxa de criação de APIs indicam que essa mudança terá impacto significativo nos mercados de entrega e segurança de aplicativos.
Já estamos vendo o início da disrupção baseada em API no setor na forma de produtos e serviços focados especificamente em observabilidade de API, segurança, inteligência de ameaças e federação.
Essas mudanças não ocorrem no vácuo. De fato, a mudança na entrega de aplicativos causada por microsserviços deveu-se em grande parte à ampla adoção do Kubernetes e sua decisão arquitetônica de incorporar diretamente recursos tradicionalmente oferecidos por tecnologias de entrega de aplicativos, como controladores de entrada (roteamento L7).
A mudança da API não é diferente, e as tendências atuais indicam que essa mudança impulsionará o surgimento do GraphQL, uma abordagem para projetar APIs que interage mais diretamente com os dados e aborda questões de desempenho com soluções baseadas em REST e, mais importante, incorporará recursos de entrega de aplicativos em seu conjunto de recursos principais.
O domínio das APIs está impulsionando o que os analistas chamam de “arquitetura headless”; ou seja, recursos e funções de negócios expostos como APIs sem a camada de apresentação tradicional. Essa arquitetura é frequentemente discutida no contexto de "aplicativos componíveis", outra tendência de tecnologia de enceramento que está surgindo no mercado.
Arquiteturas headless são uma boa opção para atender à necessidade de soluções de baixo código/sem código, pois as APIs são uma maneira prática de fornecer lógica componível que é facilmente personalizável sem esforço considerável. A arquitetura headless também atende à necessidade de compor serviços digitais a partir de uma variedade de aplicativos, serviços e sistemas, e são formas eminentemente práticas de integrar cargas de trabalho distribuídas, como já evidenciado pelo mercado de IoT predominantemente orientado por API.
Portanto, parece sensato dizer que a próxima mudança nas tecnologias de entrega e segurança de aplicativos será impulsionada por APIs, o que levará as arquiteturas headless ao mainstream.
O impacto mais significativo será na entrega de API e nos serviços de segurança. Há muito tempo o mercado trata as APIs simplesmente como um caso de uso especializado de entrega e segurança de aplicativos da web. Essa mudança exporá a realidade de que as APIs são uma classe separada de entidades com necessidades específicas de entrega e segurança que não podem ser atendidas por meios tradicionais. Isso é especialmente verdadeiro ao explorar o impacto dos serviços de dados expostos diretamente por meio de APIs. Durante a maior parte da história, os dados foram expostos apenas por meio de aplicativos . A exposição direta por meio de uma API é uma mudança significativa por si só, mas fornece o exemplo perfeito de por que as APIs não são mais um subconjunto de aplicativos da web, mas um componente arquitetônico discreto por si só.
Essa mudança nas arquiteturas de aplicativos também está ocorrendo em um momento em que as abordagens de API também mudam historicamente, geralmente em resposta à maneira como as APIs são usadas. Todas as APIs são usadas para trocar dados, mas com o tempo o tipo e o formato desses dados mudam para refletir as restrições e os recursos da arquitetura do aplicativo. Por exemplo, REST e JSON se tornaram populares junto com uma mudança em direção a dispositivos móveis e microsserviços como resposta à necessidade de trocas de dados mais frequentes e ao poder de computação reduzido das plataformas móveis. SOAP e XML exigiam análise extensa e consumiam largura de banda excessiva. REST e JSON reduziram a carga aproveitando construções HTTP existentes para descrever endpoints e mudando para um formato de dados mais simples em JSON.
No entanto, tanto SOAP/XML quanto REST/JSON exigem conjuntos de habilidades tradicionais de desenvolvedor, e a tendência é para low-code/no-code, o que pressupõe pouca ou nenhuma habilidade de desenvolvedor. GraphQL é uma linguagem de consulta simples, voltada para não desenvolvedores e altamente afim de ferramentas simples que a tornam disponível para um conjunto mais amplo de usuários. Isso torna as APIs acessíveis e combináveis em serviços digitais de todos os tipos. Isso o torna um substituto perfeito para REST/JSON à medida que as arquiteturas migram para API somente (headless).
GraphQL é a solução favorita atual para o problema de proliferação de APIs e os mesmos problemas de desempenho que ajudaram a impulsionar a mudança de SOA (arquitetura orientada a serviços) para REST. O GraphQL também tem o benefício de uma especificação , que está ajudando a impulsionar o desenvolvimento de soluções de baixo código/sem código que oferecem alívio ao desafio imposto pela escassez de talentos.
Por fim, como o GraphQL consulta APIs, e a grande maioria dos armazenamentos de dados hoje são habilitados para API, as soluções baseadas em GraphQL podem efetivamente eliminar o "intermediário" do aplicativo e ir diretamente para a própria fonte de dados. Isso é particularmente útil para aplicativos distribuídos que precisam de acesso rápido e direto a dados em locais remotos.
Isso coloca o GraphQL em uma ótima posição para atuar como um “gateway” para a arquitetura headless, da mesma forma que os controladores de entrada surgiram para atuar como o “gateway” para a arquitetura de microsserviços.
Dizem que a única constante é a mudança, e isso vale para a tecnologia. Raramente ficamos parados por mais de alguns anos antes que alguém mude as regras do jogo. No mundo da entrega e segurança de aplicativos, essas regras são parcialmente definidas pelas arquiteturas de aplicativos. Dessa forma, nenhuma mudança significativa nas arquiteturas de aplicativos ocorre sem que isso atue como uma função de força para que a entrega e a segurança do aplicativo também evoluam.
Essa mudança ainda levará alguns anos, mas você já pode ver o profundo impacto que tecnologias como GraphQL e APIs estão tendo em tudo, desde a infraestrutura até a entrega de aplicativos.
A arquitetura headless está em ascensão, e o GraphQL desempenhará um papel significativo.