It occurs to me that the situation in the infrastructure-as-a-service space today is somewhat similar to the beginning of the microprocessor era. Processors are designed for the end user (programmer), provide a rich variety of functions and hide a ton of machinery behind invocation of simple commands (think about all of the complexity that is required to deal with binary-coded decimals, for instance). Because there’s so much going on behind the scenes, it’s hard to optimize the code that is running on the processor, and sophisticated programs require custom hardware to run efficiently.

Things changed when RISC processors entered the market. They were designed to serve compilers, not programmers and hence allowed for much more freedom of expression with less primitives as opposed to first-generation microprocessors. On one hand, it was much easier for the complier to generate optimized code. On the other hand, writing a large program for the microprocessor by hand, without any help from a higher-level compiler became next to impossible.

Advent of high-level programming languages and RISC architectures led to decoupling of the language roadmap and infrastructure roadmap, allowing innovation to happen independently on each layer of the stack. Transition from CISC to RISC architectures is sometimes cited as a pre-requisite for Moore’s law to hold.

The idea should be pretty clear by now: instead of designing APIs for the programmers, design them for the compilers. Expose internals of the platform. If your platform is successful, people will try to do weird stuff with it — stuff you can’t even imagine while designing the API. If there’s a need for a more high-level API, build it on top of the low-level, high-granular ones. (Actually, more and more programmers today actually use high-level abstraction libraries like libcloud or jclouds instead of calling your API directly.)

So the question is — if “RISCy” API to your cloud provider is so appealing, both for the provider and a consumer, why don’t we see those kind of offerings on the market?

One explanation would be that the offerings are just not mature enough to be able to plan ahead. Most of the infrastructure-as-a-service providers today came from hosting business and their APIs tend to reflect their UIs, despite that the user persona has changed dramatically. Even the flagship of infrastructure-as-a-service, Amazon AWS, was not on the market for long, and even three years ago the applications that run on AWS [were just not sophisticated enough] to take full advantage of the fluid infrastructure. However, there’s different (and more profound) explanation out there.

When I described this thought to a colleague of mine, who actually happened to witness the rise of RISC first-hand, he was quick to point out that RISC could not have happened until there was a trusted compiler from a high-level language. In a sense, there’s no sense in providing low-level APIs unless there’s no popular accepted tool to take advantage of them.

Is this a problem of chicken and egg? Probably not. A successful compiler(s) could very well target providers of today and take advantage of the next-gen APIs when they arrive. For portability sake, there might be a need for a common API that can be extended with vendor-specific features (think i386 architecture and extensions made by Intel and IBM). The two most likely contenders for this abstraction layer today could be AWS API or OpenStack API; neither, however, are low-level enough to become the foundation for the next-gen offerings.

It’s pretty clear that there are bits and pieces of the stack that are available today. In the later posts I’ll try to explore the relationship between processors, high-level language compilers and operating systems and how they map to cloud landscape — what’s there already and what’s still missing.