Not Forgotten

Since the release of ChatGPT last November, it has sucked all the air out of technology discussions. This may be well deserved—in some respects, large language models represent the biggest step forward in computing since the PC. But it makes me wonder what topics aren’t getting the attention that they deserve.

Two topics that started the year strong have fallen off the radar: blockchain-related technologies and “the Metaverse,” whatever that is. A few cryptocurrency crashes coupled with a lot of fraud has soured a lot of people on the crypto world. I’ve never been a strong believer in crypto as an investment, as cash, or even as a way to own digital artworks. However, I wouldn’t write off NFTs and blockchains just yet. Public ledgers may appear to be a technology looking for a solution, but projects like the State of California’s effort to put auto registration on a blockchain are likely to simplify the painful process of dealing with the Department of Motor Vehicles. NFTs may look like making a trip to the grocery store and framing the receipt, but a small (and growing) number of companies are building customer loyalty programs that are essentially NFTs. What’s important about these efforts is that nobody needs to know what’s underneath. No customer ever has to deal with OpenSea, create a wallet, or pay GAS fees.  The underlying technology is well-hidden—as it should be. We wouldn’t have wireless networks in our homes if operating a “home network” meant hacking routers, switches, and hosts 1990-style. Customers want technology that “just works.”

The Metaverse has had a different non-history. Facebook renamed itself, and then found out that nobody could agree on what the Metaverse was—at least in part because Facebook’s ideas were, well, lame. We didn’t need “better meetings,” with participants sitting on a couch in a virtual living room. We didn’t need avatars with legs. It’s unclear to me why anyone ever thought those features would give us better meetings. “Better meetings” means fewer meetings. We need better tools for collaboration, so that we don’t need as many meetings to stay in sync. Adobe’s $20B acquisition of Figma shows just how important collaboration is. And that leads us to a different kind of metaverse: not about meetings, but about collaboration, about presence while collaborating, about doing things with your colleagues and associates. Is it a walled garden, owned by an Internet giant? Absolutely not. Is crypto required? No, though blockchains and other technologies may prove useful. Are VR goggles required? Maybe, for some applications. This isn’t Zuckerberg’s Metaverse, nor is it some crypto bro’s Metaverse. It is a way of working and collaborating despite distances and physical isolation. We’ve had “proofs of concept” for a long time, including products like Zoom and mmhmm; now it’s time to build the real thing.

However, if we’re going to get serious about technologies that have suffered when all the air got sucked out of the room, we have to go beyond the overhyped meme-techs. What technologies are underhyped or never hyped? What do we need to hear more about?

Cyber Security

Citing similar data from both Microsoft and Google, a report from the NSA recently claimed that roughly 70% of all software security vulnerabilities result from memory safety issues. That is, unfortunately, entirely too believable. The first widely destructive cyberattack was the 1988 Morris Worm, which exploited a problem in the way C programs managed memory. 35 years later, the problem hasn’t gone away, even though most programming languages that have appeared since 1990 provide some kind of memory safety. C and C++ still require programmers to do much of their own memory management. Memory-safe languages like Java and Python automate allocating and deallocating memory, though there are still ways to work around the languages’ built-in protections. Rust, which is growing in popularity, provides even more stringent guarantees of memory safety. And Zig, a newer language that’s worth investigating, provides a different set of guarantees.

Ever since the SolarWinds attack, there’s been a lot of talk about the software supply chain. There’s a good market for new tools that build software “bills of materials” listing all the libraries on which your software depends. But knowing your dependencies only solves part of the problem.  The VEX standard provides machine readable vulnerability reports. That standard allows organizations to do a better job of analyzing their risks and understanding where they are vulnerable. Ultimately, though, a bigger problem needs to be addressed: how do organizations keep their software updated with security patches?

In 2022, security wasn’t in the news as often as it was in 2020 and 2021. But that doesn’t mean it’s time to relax.

Decentralized Computing

What about the Fediverse? That’s the network of decentralized, loosely-coupled services that are held together by network protocols: often ActivityPub, but also IPFS, Scuttlebutt, BlueSky, and others. Mastodon is the most well-known example of the Fediverse; it’s a Twitter-like service that, in the days since Elon Musk’s Twitter abuse, has scaled by a factor of 10, from roughly 1 million to over 10 million users. The growth hasn’t been without pain, but outages have been few and (partly due to the decentralized nature of the protocol) limited. Another factor of 10 would take Mastodon to Twitter scale; a second factor of 10 would be Facebook scale. Can this kind of technology reach Facebook scale? So far, the answer appears to be “yes.”  Whether the industry pundits can learn to take seriously a service that has no multi-billionaires or VCs behind it is a different question.

Past Mastodon, there are a number of other decentralized technologies that people should know about. CRDTs (Conflict Free Replicated Data Types) are behind tools like Google Docs, which lets multiple users edit a document simultaneously. An open source CRDT library from the Ink & Switch project promises to make decentralized applications much easier to build. J. Chris Anderson has been arguing for “cloudless” computing, in which the centralized corporate cloud providers are replaced by protocol-based networks of ambient computing power. Ion Stoica’s Sky Computing lab is building the software for another vision of disaggregated computing. Stoica’s name may not be as familiar as Zuck’s or Musk’s, but both Apache Spark and Ray originated in his labs. Is this an idea whose time has come?

A Programming Platform for the Web

WebAssembly (WASM) has been around for a few years now; it isn’t new. But it has been growing slowly, and demonstrating value as a computing platform for the Web. WebAssembly provides a browser-based compilation target for high-level languages ranging from C to Rust (including C++, C#, Python, and Ruby). This means that developers can write programs in any of these languages that will run in a browser, without using JavaScript. Developers are beginning to use WASM for servers and other applications that run outside of the browser.

Why is WASM needed? Is it just because JavaScript is a confusing, poorly defined language? Well, partly. Many have noted that JavaScript: The Good Parts is 175 pages long, while JavaScript: The Definitive Guide is 704 pages long. The comparison isn’t fair, but it can’t be ignored, either. More to the point: what would it mean to run servers and other applications in the browser? What if the browser becomes more than a display engine? We’ve seen WASM running the Jupyter server, allowing users to run Jupyter Notebooks without leaving the browser—and in the process, eliminating security issues that trouble large enterprises. The Figma collaborative design tool uses WASM. What else? Will this be WASM’s breakout year?

Database Proliferation

Years ago, I wrote that NoSQL wasn’t a database technology; it was a movement. It was a movement that affirmed the development and use of database architectures other than the relational database. It was about choice: there was nothing wrong with MySQL or Oracle when you needed a relational database, but there were few alternatives. Your square peg had to fit a round hole.

While more than a few people are saying that relational databases have won out, it’s important to realize that there are database options, and plenty of them. Lately, I’ve been reading about Pinecone DB, a vector database that looks like it will be a good match for AI applications. DuckDB is a SQL database (yes, relational) that is designed for integration directly into applications, not unlike SQLite. There has been a proliferation of time series and graph databases. Fireproof is a new database designed for “cloudless” applications. So, while NoSQL might not be the rallying cry it once was, it has won the day—not in the sense of replacing relational databases (which was never the real issue), but in the sense of providing alternative database designs and architectures to fit different kinds of applications.

Simpler Container Management

Kubernetes has dominated container orchestration for several years now. That domination hasn’t been without its problems; Kubernetes is complex and has a steep learning curve. Is it time for something simpler, something that is easier to understand and configure?

To understand the difficulty of replacing Kubernetes we have to start with its history, which is unlike most open source projects. It started as an open source release of Google’s Borg: the internal platform that managed their vast infrastructure. Therefore, in its initial release, it was close to fully-formed. It was designed with Google’s engineering staff in mind, and included almost everything you would need to run Google. It wasn’t an initial bare-bones release to which developers gradually added new features. It was complex from the start; it didn’t become complex through a long, slow process that took years.

The problem with a project that starts out fully formed is that, rather than make do with a simple feature set, early adopters can do anything they want. They can build a complete enterprise-scale container orchestration system, whether they need it or not. And perhaps they do need it—but that leads to my own version of the 80/20 rule. 80% of the users need 20% of the features. But 100% of the users need one special feature that’s not in the 20%. As a result, it’s very difficult to imagine a simpler solution that actually works for more than a small number of users. 

Some alternatives have appeared, including managed Kubernetes, where you delegate management of your cluster to a third party, typically your cloud provider; HashiCorp’s Nomad; K3S, a lightweight Kubernetes; and even some older tools like Docker Swarm. It’s anyone’s guess whether any of these tools will come to dominance, or whether developers will stick with Kubernetes, complex as it may be.

What other trends and technologies are we missing?