Desde o lançamento do ChatGPT em novembro passado, ele sugou todo o ar das discussões sobre tecnologia. Isso pode ser bem merecido – em alguns aspectos, grandes modelos de linguagem representam o maior avanço na computação desde o PC. Mas isso me faz pensar quais tópicos não estão recebendo a atenção que merecem.
Dois tópicos que começaram o ano com força saíram do radar: tecnologias relacionadas a blockchain e “o metaverso”, seja lá o que isso for. Algumas falhas de criptomoeda, juntamente com muitas fraudes, azedaram muitas pessoas no mundo criptográfico. Nunca acreditei muito em criptografia como investimento, como dinheiro ou mesmo como uma forma de possuir obras de arte digitais. No entanto, eu não descartaria NFTs e blockchains ainda. Livros públicos podem parecer uma tecnologia em busca de uma solução, mas projetos como o esforço do estado da Califórnia para colocar registro automático em um blockchain provavelmente simplificarão o doloroso processo de lidar com o Departamento de Veículos Motorizados. Os NFTs podem parecer como fazer uma viagem ao supermercado e emoldurar o recibo, mas um pequeno (e crescente) número de empresas estão construindo programas de fidelidade do cliente que são essencialmente NFTs. O que é importante sobre esses esforços é que ninguém precisa saber o que está por baixo. Nenhum cliente precisa lidar com a OpenSea, criar uma carteira ou pagar taxas de GAS. A tecnologia subjacente está bem escondida – como deveria ser. Não teríamos redes sem fio em nossas casas se operar uma “rede doméstica” significasse hackear roteadores, switches e hosts no estilo de 1990. Os clientes querem uma tecnologia que “simplesmente funcione”.
O Metaverso teve uma não-história diferente. O Fb renomeou a si mesmo e depois descobriu que ninguém concordava com o que period o Metaverso – pelo menos em parte porque as ideias do Fb eram, bem, esfarrapadas. Não precisávamos de “reuniões melhores”, com os participantes sentados no sofá de uma sala de estar digital. Não precisávamos de avatares com pernas. Não está claro para mim por que alguém pensou que esses recursos nos proporcionariam reuniões melhores. “Reuniões melhores” significam menos reuniões. Precisamos de melhores ferramentas para colaboração, para que não precisemos de tantas reuniões para ficar em sincronia. Aquisição da Figma por US$ 20 bilhões pela Adobe mostra o quão importante é a colaboração. E isso nos leva a um tipo diferente de metaverso: não sobre reuniões, mas sobre colaboração, sobre presença enquanto colabora, sobre fazer coisas com seus colegas e associados. É um jardim murado, propriedade de um gigante da Web? Absolutamente não. A criptografia é necessária? Não, embora blockchains e outras tecnologias possam ser úteis. Os óculos de realidade digital são necessários? Talvez, para algumas aplicações. Este não é o Metaverso de Zuckerberg, nem é o Metaverso de algum irmão criptográfico. É uma forma de trabalhar e colaborar apesar das distâncias e do isolamento físico. Há muito tempo temos “provas de conceito”, incluindo produtos como Zoom e mmhmm; agora é hora de construir a coisa actual.
No entanto, se quisermos levar a sério as tecnologias que sofreram quando todo o ar foi sugado para fora da sala, temos que ir além dos meme-techs exagerados. Quais tecnologias são subestimadas ou nunca divulgadas? O que precisamos ouvir mais?
Cíber segurança
Citando dados semelhantes da Microsoft e do Google, um relatório da NSA afirmou recentemente que cerca de 70% de todas as vulnerabilidades de segurança de software program resultam de problemas de segurança de memória. Isso é, infelizmente, muito crível. O primeiro ciberataque amplamente destrutivo foi o de 1988 Morris Worm, que explorou um problema na maneira como os programas C gerenciavam a memória. 35 anos depois, o problema não desapareceu, embora a maioria das linguagens de programação que surgiram desde 1990 forneçam algum tipo de segurança de memória. C e C++ ainda exigem que os programadores façam grande parte de seu próprio gerenciamento de memória. Linguagens seguras para memória, como Java e Python, automatizam a alocação e desalocação de memória, embora ainda existam maneiras de contornar as proteções integradas das linguagens. Rust, que está crescendo em popularidade, fornece garantias ainda mais rigorosas de segurança de memória. E Ziguma linguagem mais recente que vale a pena investigar, fornece um conjunto diferente de garantias.
Desde o SolarWinds ataque, tem havido muita conversa sobre a cadeia de suprimentos de software program. Há um bom mercado para novas ferramentas que criam “listas de materiais” de software program listando todas as bibliotecas das quais seu software program depende. Mas conhecer suas dependências resolve apenas parte do problema. O VEX padrão fornece relatórios de vulnerabilidade legíveis por máquina. Esse padrão permite que as organizações façam um trabalho melhor ao analisar seus riscos e entender onde estão vulneráveis. Em última análise, porém, um problema maior precisa ser resolvido: como as organizações mantêm seus softwares atualizados com patches de segurança?
Em 2022, a segurança não esteve nos noticiários com tanta frequência quanto em 2020 e 2021. Mas isso não significa que é hora de relaxar.
Computação Descentralizada
E o Fediverso? Essa é a rede de serviços descentralizados e fracamente acoplados que são mantidos juntos por protocolos de rede: muitas vezes ActivityPubmas também IPFS, Scuttlebutt, Céu azule outros. Mastodonte é o exemplo mais conhecido do Fediverso; é um serviço semelhante ao Twitter que, desde o abuso do Twitter de Elon Musk, aumentou em um fator de 10, de aproximadamente 1 milhão para mais de 10 milhões de usuários. O crescimento não foi isento de dor, mas as interrupções foram poucas e (em parte devido à natureza descentralizada do protocolo) limitadas. Outro fator de 10 levaria o Mastodon à escala do Twitter; um segundo fator de 10 seria a escala do Fb. Esse tipo de tecnologia pode atingir a escala do Fb? Até agora, a resposta parece ser “sim”. Se os especialistas do setor podem aprender a levar a sério um serviço que não tem multibilionários ou VCs por trás dele, é uma questão diferente.
Depois do Mastodon, existem várias outras tecnologias descentralizadas que as pessoas devem conhecer. CRDTs (Battle Free Replicated Knowledge Sorts) estão por trás de ferramentas como o Google Docs, que permite que vários usuários editem um documento simultaneamente. Um código aberto biblioteca CRDT do projeto Ink & Swap promete tornar os aplicativos descentralizados muito mais fáceis de construir. J. Chris Anderson tem defendido computação “sem nuvens”, em que os provedores de nuvem corporativos centralizados são substituídos por redes baseadas em protocolo de poder de computação ambiente. Ion Stoica’s Sky Computing lab está construindo o software program para outra visão da computação desagregada. O nome de Stoica pode não ser tão acquainted quanto o de Zuck ou Musk, mas ambos Apache SparkGenericName e Raio surgiu em seus laboratórios. Esta é uma ideia cuja hora chegou?
Uma plataforma de programação para a Net
WebAssembly (WASM) já existe há alguns anos; não é novo. Mas vem crescendo lentamente e demonstrando valor como plataforma de computação para a Net. O WebAssembly fornece um destino de compilação baseado em navegador para linguagens de alto nível, variando de C a Rust (incluindo C++, C#, Python e Ruby). Isso significa que os desenvolvedores podem escrever programas em qualquer um desses idiomas que serão executados em um navegador, sem usar JavaScript. Os desenvolvedores estão começando a usar o WASM para servidores e outros aplicativos executados fora do navegador.
Por que o WASM é necessário? É só porque o JavaScript é uma linguagem confusa e mal definida? Bem, em parte. Muitos notaram que JavaScript: as partes boas tem 175 páginas, enquanto JavaScript: o guia definitivo tem 704 páginas. A comparação não é justa, mas também não pode ser ignorada. Mais direto ao ponto: o que significaria executar servidores e outros aplicativos no navegador? E se o navegador se tornar mais do que um mecanismo de exibição? Vimos o WASM executando o servidor Jupyter, permitindo que os usuários executem Jupyter Notebooks sem sair do navegador e, no processo, eliminando problemas de segurança que incomodam grandes empresas. O figma ferramenta de design colaborativo usa WASM. O que mais? Este será o ano de estreia do WASM?
proliferação de banco de dados
Anos atrás, escrevi que NoSQL não period uma tecnologia de banco de dados; foi um movimento. Foi um movimento que afirmou o desenvolvimento e uso de arquiteturas de banco de dados diferentes do banco de dados relacional. Period uma questão de escolha: não havia nada de errado com MySQL ou Oracle quando você precisava de um banco de dados relacional, mas havia poucas alternativas. Seu pino quadrado tinha que caber em um buraco redondo.
Embora muitas pessoas digam que os bancos de dados relacionais venceram, é importante perceber que existem opções de banco de dados, e muitas delas. Ultimamente, tenho lido sobre Pinha DBum banco de dados vetorial que parece ser uma boa combinação para aplicativos de IA.DuckDBName é um banco de dados SQL (sim, relacional) projetado para integração direta em aplicativos, não muito diferente do SQLite. Houve uma proliferação de série temporal e gráfico bancos de dados.A prova de fogo é um novo banco de dados projetado para aplicativos “sem nuvem”. Portanto, embora o NoSQL possa não ser o grito de guerra que já foi, ele ganhou o dia – não no sentido de substituir bancos de dados relacionais (o que nunca foi o problema actual), mas no sentido de fornecer designs e arquiteturas de banco de dados alternativos para atender diferentes tipos de aplicações.
Gerenciamento de contêineres mais simples
O Kubernetes domina a orquestração de contêineres há vários anos. Essa dominação não foi isenta de problemas; O Kubernetes é complexo e tem uma curva de aprendizado acentuada. É hora de algo mais simples, algo mais fácil de entender e configurar?
Para entender a dificuldade de substituir o Kubernetes temos que começar com sua história, que é diferente da maioria dos projetos de código aberto. Começou como um lançamento de código aberto do Borg do Google: a plataforma interna que gerenciava sua vasta infraestrutura. Portanto, em seu lançamento inicial, estava quase totalmente formado. Ele foi projetado com a equipe de engenharia do Google em mente e inclui quase tudo o que você precisa para executar o Google. Não foi um lançamento inicial básico ao qual os desenvolvedores gradualmente adicionaram novos recursos. Foi complexo desde o início; não se tornou complexo por meio de um processo longo e lento que levou anos.
O problema com um projeto que começa totalmente formado é que, em vez de se contentar com um simples conjunto de recursos, os primeiros usuários podem fazer o que quiserem. Eles podem criar um sistema completo de orquestração de contêineres em escala empresarial, precisando ou não. E talvez eles precisem disso – mas isso leva à minha própria versão da regra 80/20. 80% dos usuários precisam de 20% dos recursos. Mas 100% dos usuários precisam de um recurso especial que não está nos 20%. Como resultado, é muito difícil imaginar uma solução mais simples que realmente funcione para mais do que um pequeno número de usuários.
Algumas alternativas surgiram, incluindo Kubernetes gerenciado, onde você delega o gerenciamento do seu cluster a terceiros, geralmente seu provedor de nuvem; da HashiCorp Nômade; K3S, um Kubernetes leve; e até mesmo algumas ferramentas mais antigas como Docker Swarm. Ninguém sabe se alguma dessas ferramentas dominará ou se os desenvolvedores continuarão com o Kubernetes, por mais complexo que seja.
Que outras tendências e tecnologias estamos perdendo?