New technologies can take many forms. Often, they come from generally straightforward, incremental product advances over the course of years; think the Complementary Metal-Oxide-Semiconductor (CMOS) process shrinks that underpinned many of the advances in computing over the past decades. Not easy, but relatively predictable from a high-level enough view.

Other shifts are less straightforward to predict. Even if a technology is not completely novel, it may require the right conditions and advances to come together so it can flourish in the mainstream. Both server virtualization and containerization fall into this category.

What’s next? Someone once said that predictions are hard, especially about the future. But here are some areas that Red Hat has been keeping an eye on and that you should likely have on your radar as well. This is hardly a comprehensive list and it may include some surprises, but, it is a combination of both early stage and more fleshed-out developments on the horizon. The first few are macro trends that pervade many different aspects of computing. Others are more specific to hardware and software computing infrastructure.

Artificial intelligence/machine learning (AI/ML)

On the one hand, AI/ML belongs on any list about where computing is headed. Whether coding tools, self-tuning infrastructure, or improved observability of systems, AI/ML is clearly a critical part of the computing landscape going forward.

What’s harder to predict is exactly what forms and applications of AI will deliver compelling business value, many of which will be interesting in narrow domains, and will likely turn out to be almost good enough over a lengthy time horizon.

Much of the success of AI to date has rested on training deep neural networks (NNs) of increasing size (as measured by the number of weights and parameters) on increasingly large datasets using backpropagation, and supported by the right sort of fast hardware optimized for linear algebra operations—graphics processing units (GPUs) in particular. Large Language Models (LLMs) are one prominent, relatively recent example.

There have been many clear wins, but AI has struggled with more generalized systems that interface with an unconstrained physical world—as in the case of autonomous driving, for example. There are also regulatory and legal concerns relating to explainability, bias and even overall economic impact. Some experts also wonder if broad gaps in our collective understanding of the many areas covered by cognitive science that lay outside the direct focus of machine learning may (or may not) be needed for AI to handle many types of applications.

What’s certain is that we will be surprised.

Automation

In a sense, automation is a class of application to which AI brings more sophisticated capabilities. For example, Red Hat Ansible Lightspeed with IBM watsonx Code Assistant is one recent example of a generative AI service designed by and for Ansible automators, operators and developers.

Automation is increasingly necessary because hardware and software stacks are getting more complex. What’s less obvious is how improved observability tooling and AI-powered automation tools that make use of that more granular data plays out in detail.

At the least, it will lead us to think about questions such as: Where are the big wins in dynamic automated system tuning that will most improve IT infrastructure efficiency? What’s the scope of the automated environment? How much autonomy will we be prepared to give to the automation, and what circuit breakers and fallbacks will be considered best practice?

Over time, we’ve reduced manual human intervention in processes such as CI/CD pipelines. But we’ve done so in the context of evolving best practices in concert with the increased automation.

Security

Security is a broad and deep topic (and one of deep concern across the industry). It encompasses zero trust, software supply chains, digital sovereignty and yes, AI—both as a defensive tool and an offensive weapon. But one particular topic is worth highlighting here.

Confidential computing is a security technology that protects data in use, meaning that it is protected while it is being processed. This is in contrast to traditional encryption technologies, which protect data at rest (when it is stored) and data in transit (when it is being transmitted over a network).

Confidential computing works by using a variety of techniques to isolate data within a protected environment, such as a trusted execution environment (TEE) or a secure enclave. It’s of particular interest when running sensitive workloads in an environment over which you don’t have full control, such as a public cloud. It’s relatively new technology but is consistent with an overall trend towards more security controls, not fewer.

RISC-V

While there are examples of open hardware designs, such as the Open Compute Project, it would be hard to make the case for there having been a successful open processor relevant to server hardware.

However, major silicon vendors and cloud providers are exploring and adopting the RISC-V free-to-license and open processor instruction set architecture (ISA). It follows a different approach from past open processor efforts. For one thing, it was open source from the beginning and is not tied to any single vendor. For another, it was designed to be extensible and implementation-agnostic. It allows for the development of new embedded technologies implemented upon FPGAs as well as the manufacture of microcontrollers, microprocessors and specialized data processing units (DPUs).

Its impact is more nascent in the server space, but it has been gaining momentum. The architecture has also seen considerable standardization work to balance the flexibility of extensions with the fragmentation they can bring. RISC-V profiles are a set of standardized subsets of the RISC-V ISA. They are designed to make sure that hardware implementers and software developers can intersect with an interface built around a set of extensions with a bounded amount of flexibility designed to support well-defined categories of systems and applications.

Platform software

Perhaps one of the most intriguing questions is what happens at the lower levels of the server infrastructure software stack—roughly the operating system on a single shared memory server and the software that orchestrates workloads across many of these servers connected over a network.

It is probably easiest to start with what is unlikely to change in fundamental ways over the next decade. Linux has been around for more than 30 years; Unix more than 50, with many basic concepts dating to Multics about ten years prior.

That is a long time in the computer business. But it also argues for the overall soundness and adaptability of the basic approach taken by most modern operating systems—and the ability to evolve Linux when changes have been needed. That adaptation will continue by taking advantage of reducing overheads by selectively offloading workloads to FPGAs and other devices such as edge servers. There are also opportunities to reduce transition overheads for performance-critical applications; the Unikernel Linux project—a joint effort involving professors, PhD students and engineers at the Boston University-based Red Hat Collaboratory—demonstrates one direction such optimizations could take.

More speculative is the form that collections of computing resources might take and how they will be managed. Over the past few decades, these resources primarily took the form of masses of x86 servers. Some specialized hardware is used for networking, storage and other functions, but CMOS process shrinks meant that for the most part, it was easier, cheaper and faster to just wait for the next x86 generation than to buy some unproven specialized design.

However, with performance gains associated with general-purpose process shrinks decelerating—and maybe even petering out at some point—specialized hardware that more efficiently meets the needs of specific workload types starts to look more attractive. The use of GPUs for ML workloads is probably the most obvious example, but is not the only one.

The challenge is that developers are mostly not increasing in number or skill. Better development tools can help to some degree, but it will also become more important to abstract away the complexity of more specialized and more diverse hardware.

What might this look like? A new abstraction/virtualization layer? An evolution of Kubernetes to better understand hardware and cloud differences, the relationship between components and how to intelligently match relatively generic code to the most appropriate hardware or cloud? Or will we see something else that introduces completely new concepts?

Wrap up

What we can say about these predictions is that they’re probably a mixed bag. Some promising technologies may fizzle a bit. Others will bring major and generally unexpected changes in their wake, and something may pop onto the field at a time and from a place where we least expect it.