This post is first of the 3-part History of PaaS series.

‍

When you hear the term “PaaS” (i.e. Platform as a Service), Heroku is probably the first platform that comes to your mind. However, while Heroku did play a significant role in establishing PaaS as its own class of product, it was not the first of its kind. One of the very first PaaS offerings in history actually belonged to Canon (yes, the camera company), until it was abruptly killed by Canon itself. In this blog post, we’ll delve into the story of Zimki, a Platform as a Service that was unfortunately too ahead of its time.

The Birth of AWS and its Primitives

Zimki was created around 2006 - the same year Amazon launched S3 and EC2 that laid the groundwork for what would become AWS. AWS began the era of Infrastructure as a Service (IaaS), a foundational layer on which PaaS’s are built, and is thus inextricably tied to the story of Zimki.

‍

S3 and EC2 were born out of a need to address internal developer slowdown at Amazon. Amazon’s executives found that their engineers were spending too much time building compute, storage, and database components from scratch, so they sought out to build a common set of infrastructure that developers can reuse instead of reinventing the wheel each time they’re building a new application.^[1]

‍

Apparently, the idea behind AWS was partly motivated by a book that Jeff Bezos had read, called Creation: Life and How to Make It. The book was written by Steve Grand, a developer of a 1990s video game called Creatures. Creatures was “an artificial life simulation where the user hatches small furry animals and teaches them how to behave, or leaves them to learn on their own”.^[2]

‍

These furry animals were seemingly intelligent, and Grand wrote that “his approach to creating intelligent life was to focus on designing simple computational building blocks, called primitives, and then sit back and watch surprising behaviors emerge.”^[3] In a world of GPT-3 and the proliferation of neural networks, this may appear to be a non-statement. But this then-counterintuitive idea gained popularity in the book clubs of Amazon executives and guided much of what AWS sought to achieve. Rather than “guess” what kind of higher level services the developers would want, Amazon executives wanted to provide a set of primitives, the simplest atomic components of infrastructure, that developers can combine to build sophisticated applications with as much flexibility as possible.^[4]

Indeed, this approach was a huge success internally and Amazon was quick to expand its primitives to developers outside the company. The rest is history. Here is a quote from The Everything Store that describes how EC2 and S3 went on to revolutionize the tech world:

“Just like Creation author Steve Grand had predicted, the creatures were evolving in ways that Bezos could not have imagined. It was the combination of EC2 and S3—storage and compute, two primitives linked together—that transformed both AWS and the technology world. Startups no longer needed to spend their venture capital on buying servers and hiring specialized engineers to run them. Infrastructure costs were variable instead of fixed, and they could grow in direct proportion to revenues. It freed companies to experiment, to change their business models with a minimum of pain.”

We take the cloud for granted now, but startups literally had to buy physical servers and go to a physical datacenter before AWS came about. As a developer in my 20s, I can’t even imagine what that feels like. Here is a thread from Dalton, our partner at YC, on what running servers looked like back then:

AWS significantly lowered the barrier to entry for those who want to build and run applications at scale (removed the “muck” as Bezos would describe), but its focus on “primitives” put an inherent limit to how much it could make the deployment process easier. In other words, AWS excelled at providing the building blocks but still left the onus of combining those building blocks to the developer. As discussed above, this was very much an intentional choice to maximize flexibility.

‍

This guiding philosophy helped EC2 and S3 become the standard, ubiquitous units of the web but left room for other players to abstract the deployment process even further by building on top of the nascent IaaS layer.

Zimki: Beyond the primitives

Zimki was a platform created by a company named Fotango, an online photo sharing website that was acquired by Canon in 2002 after the dot-com boom. Simon Wardley, Fotango’s acting CEO at the time, envisioned a similar future as Bezos with Zimki, where compute would be available to developers as a utility, much like how electricity is supplied through a city-wide grid.

‍

Unlike AWS, however, Zimki did not just stop at providing developers with the basic building blocks of compute and storage. Instead, it sought to own and define the developer experience around application development and deployment while abstracting away the underlying infrastructure. On Zimki, developers would write code inside the platform (via an IDE in the browser) and expose their functions as APIs that can be consumed externally. What we now call environments were called “realms”: users could easily pull code from these realms into their local machines to develop, and seamlessly clone their code across development, staging, and production realms. Users did not have to care at all about the underlying infrastructure, and billing was calculated per each function.^[5]

‍

In many ways, Zimki was years ahead of its time. It wasn’t just a precursor to what we now call PaaS - it was a PaaS with a serverless flavor that looked much like AWS Lambdas and Cloud Run of the present day.^[6]

The strategy behind Zimki was also highly unconventional for its time. Zimki had initially launched as a platform that runs on top of Fotango’s own infrastructure. However, Wardley knew that this would be very capital intensive. He also knew that other big players like Amazon and Google would sweep in with IaaS plays because they are one of the few companies that could afford to do so. Accurately predicting that the market will soon be full of IaaS providers, Wardley wanted to make Zimki the standard developer platform that can run on any infrastructure, rather than offer it solely on Fotango’s own infrastructure. Instead of becoming a dominant IaaS or PaaS provider, Wardley wanted to drive Zimki to a standard and “build the exchange, brokerage and assurance industries” on top of it.^[7]

‍

So when Amazon launched EC2 and S3, Wardley was ecstatic and quickly made a set of strategic decisions that were highly unconventional at the time - he wanted to help IaaS providers like AWS offer their own hosted version of Zimki on top of EC2, in order to drive up adoption and establish Zimki as the standard. To that end, Fotango also decided to completely open source Zimki to ease developers from the fear of vendor lock-in by allowing them to host it anywhere.^[8] Zimki was essentially an open source PaaS that could run in your own cloud (sounds like another company I know…)

Unfortunately, Wardley’s plan was met with skepticism from Canon, Fotango’s parent company. Canon did not believe that “cloud compute” was the future at the time and was even more skeptical of the decision to go completely open source. Subsequently, Canon decided to put a halt on all operations around Zimki - a decision that led Wardley to dramatically resign on the stage of OSCON, during which he had planned to announce that Zimki is going open source.^[9]

‍

That was the end of Zimki. Wardley writes in his blog, “Had Canon taken another path then it could well have become one of the largest cloud providers in today's market, rivaling those of later entrants such as Google (with AppEngine), Microsoft (with Azure)…”^[10] In an alternate universe, we’d be using CWS.

‍

However, although Zimki failed to see the light of the day, it serves as an important example for the later PaaS entrants. The ideas it brought to the table, particularly the religious aversion to vendor lock-in and its focus on the platform layer rather than the underlying infrastructure, are strikingly similar to the recent meta of the PaaS market today, in a world where Kubernetes exists.

‍

This post is part of the 3-part History of PaaS series. Subscribe to be notified for the next article. If you liked this article, share it on Twitter, HackerNews, Reddit, or LinkedIn!