Main content

My learnings from 21+ years of SaaS and cloud

Phil Wainewright Profile picture for user pwainewright May 25, 2020
Some memories and learnings from over two decades of watching the evolution of SaaS and cloud computing, as told to SaaShimi's Aznaur Midov

Red SAAS surrounded by cloud of blue words © Tashatuvango - shutterstock
(© Tashatuvango - shutterstock)

Last summer I was approached by Aznaur Midov, a tech industry banker working in San Francisco, to record a podcast about the history of Software-as-a-Service (SaaS). Having witnessed much of that history in my coverage of the industry over more than two decades — as the founder of back in 1998, ZDNet's lead blogger on SaaS from 2005, and as one of the founding team at diginomica since 2011 — I was glad to share some of my memories and lessons learned.

You can now listen to the podcast online as part of SaaShimi, a seven-part series on the business of Saas, which features some fantastic interviews with industry luminaries such as Dave Kellogg, Tracy Eiler and Bruce Cleveland. Here's a sampling of reminiscences and takeaways from my own contribution.

Why this history is relevant today

Why should we care what happened 15, 20 years ago? I believe there are two reasons. First of all, as George Santayana once said, "Those who cannot remember the past are condemned to repeat it." The early experiences of these technology pioneers hold invaluable lessons for the pioneers of today, some of which I've highlighted below.

Secondly, as I explain in the recording, these SaaS pioneers laid the foundation of the digitally connected mode of business that is spreading through every industry today:

All businesses, whether they're retailers or manufacturers, or media companies, look more and more like software companies, more and more like SaaS companies. And so I think the SaaS model — I call it XaaS, which stands for Everything-as-a-Service — becomes this XaaS model that every company has to conform to.

They've got to deliver this joined-up service, because the technology means pervasive connectivity — you are constantly connected to your customers. If you don't nurture that relationship, and concern yourself with the success your customers have with your products, then other people will take that business away.

But not every error is being repeated

One thing that is astonishing looking back at that time is how naive investors were in comparison to today. The dot-com boom was certainly an age of innocence, even if some of the losses that have been sustained in this year's market are on a larger scale. I dug out one piece of history for Midov from the boom days of ASPs, the application service providers who were the precursors of SaaS:

One of the leading ASPs in 2000 was a company called Corio, which specialized in delivering applications like PeopleSoft and Oracle to companies using all this [Windows terminal] technology. They were filing for an IPO to raise $50 million on $5.8 million revenues — of which £0.75 million were actually application services, and the other $5 million was professional services. They had a net loss of $45 million, and their IPO was very successful.

Establishing a new wave of innovation is hard work

It's easy to forget how much of a struggle it is to be a true pioneer of a breakthrough technology. So much of the technology, knowledge and infrastructure that we take for granted today simply didn't exist when the first SaaS vendors got started. There used to be deep debates about the nature of multi-tenancy and what shape it should take, whereas today it's available off-the-shelf, routinely built into the infrastructure of cloud-based containers and serverless computing.

None of the stuff that we take for granted today existed. Internet access was dial-up, there was no mobile broadband. There were none of these frameworks to support application functionality in the browser. There was much poorer global Internet infrastructure. There were no cloud platforms like AWS, and Google Cloud and Azure, there were no platforms-as-a-service like Salesforce AppExchange.

You had to build everything yourself. You had to build your own AWS and your own AppExchange, and then put your application on top of it. What multi-tenancy meant was, you basically had to — from scratch with your own innovation — create an infrastructure that meant that all of your customers were running from a single database and a single application server, but were each getting their own individual version of the application where their data was not available to anybody else in the same infrastructure.

What used to be heresy is now mainstream

Go back 15-20 years and there were huge doubts about the cloud model and the potential security and performance risks of "co-mingling" your data in the same infrastructure as other businesses.

Such arguments were used to justify retaining the existing application architectures rather than creating something new. I came to realize that when people talked about ASPs, they were generally thinking "service providers of applications" with little or no change to the applications, whereas I had always thought in terms of "providers of application services," which implied a much more componentized application architecture. 

All of those debates and doubts have now pretty much faded away. Today everyone focuses on the benefits rather than assuming there must be something wrong with sharing cloud infrastructure.

This is now mainstream. It's now called serverless. This is a convenience, that we're using the same functionality that everyone else is — because it's cheaper, it's on demand, we only pay for what we use. So we've kind of gone full circle now. What used to be an exception is now actually the norm ...

Everything is becoming much more atomized and you are literally now able to on demand, assemble the application that you need from a whole load of different services. I actually remember saying that was the future back in 1999, and it's probably taken us 20 years to get there.

Innovators have to stick with it

Everything we have today exists because a few stubborn innovators back then trusted their instincts and stood their ground. This became an even tougher choice after venture funding all but dried up in the wake of the dot-com crash — perhaps that's a lesson from history that today's entrepreneurs should take to heart.

I think that in 30 years of watching technology — and being at the leading edge really, watching the emerging stuff — the establishment always believes that what they're doing is the right way to do it, and are always dismissive of new things coming along. If you're doing a new thing — which is actually going to end up being better — then you just have to stick to it. Because it's going to be really tough for the first 10, 15, 20 years, until eventually the whole world comes around to your point of view.

Everyone who was there at the time acknowledges the huge influence of Salesforce and its CEO Marc Benioff in making a very public stand in support of the cloud-native model, but there are many others who played their part. A company called Jamcracker led an initiative to map out all the areas where the nascent industry would need new standard specifications — that early work contributed to the creation of SAML, which formed the basis of today's effortless single sign-on (SSO) infrastructure, and presaged many other shared standards we take for granted today.

Another early pioneer was Biztone, which set out to build the first cloud-native ERP suite, before funding dried up in the early 2000s. Its CEO Darryl Carlton used to talk about the disappearance of all the early mainframe financials vendors after the rise of client-server, and how the client-server giants like SAP and Oracle would eventually share the same fate at the hands of the cloud generation — a prediction that is perhaps finally starting to come true now.

The accidental hyperscalers - how AWS, Azure and GCP got started

People looking back may think, well surely Amazon and Google were around at the time and already taking a lead in cloud computing? What's interesting is that they weren't considered part of the SaaS industry, because they weren't delivering anything that was regarded as an enterprise application at the time. Even though Google made a multi-billion dollar business out of delivering Internet advertising-as-a-service to their customers, that didn't count because it wasn't a 'serious' application that you could buy from an established enterprise vendor like SAP, Oracle or IBM.

The mainstream thinking at the time was that these web giants were content destinations, not providers of functionality. But behind the scenes, the web giants were laying the foundations for much of what we take for granted in cloud computing and digital architectures today:

A lot of the work that Google did, that Yahoo did — the development of DevOps and continuous delivery, all of those things associated with the cloud infrastructure model — came out of these huge concerns that were delivering stuff across the Internet that was not the classic enterprise application, but still required enterprise-scale computing of one kind or another. And they also defined a lot of the stuff that was necessary to make this model work.

Even so, today's dominant trio of cloud hyperscale platforms each stumbled into becoming Infrastructure-as-a-Service (IaaS) providers almost by accident:

  • Amazon nearly broke. If the dot-com boom hadn't turned into a collapse, then Amazon would have fallen over because they couldn't scale. They knew that they had to rewrite their underlying infrastructure. And so they rewrote it, as effectively what you would call today micro services. And that led to AWS. Because they had created these component services, and then they thought, 'Okay, well, why don't we just try taking them to market?' So they took S3 to market and that took off so then they came out with the Elastic Compute Service and that started to take off.

  • Microsoft just happened to have tried to run a search engine, so with Bing they had some experience of how to do computing at scale. They just happened to kind of fall into delivering Office across the web as a multi-tenant service. So they started almost by accident, to have the technology and expertise in-house to to end up doing Azure.

  • Google had this incredible infrastructure and eventually decided — well, in fact, I think it was a little bit of an accident. Gmail, they didn't realize was going to be as successful as it was, and when it turned out that it was successful, they thought, 'Okay, well maybe we can get into other aspects of enterprise computing.' But it took them a long time — and they're only just getting around to understanding what they really need to do to deliver to the enterprise.

My take? Only connect

The evolution of the whole SaaS and cloud landscape over the past two decades has brought us to a point where most applications today are multi-tier, built on infrastructure run by one or more providers, enhanced with several third-party services, and often delivered via a separate messaging platform or user experience. To someone used to building applications the old way, as a single vertically integrated stack, this seems very alien. But in a digitally connected, networked world, why would you do it any differently?

Just because the software that you've developed is running on someone else's infrastructure that is taking someone else's underlying platform, and you're actually delivering it in some messaging layer that someone else is providing, doesn't make it any less yours.

Actually, you know, this is better. We live in a networked economy, and the businesses that will thrive and prosper are the ones that are the best at taking advantage of the network.

So why should it be a bad thing that you're actually taking from the network the stuff that people do best, to put that together with the stuff that you're good at, to then deliver the best products? I don't see what's wrong with that. The only people who want to build everything themselves are engineers who don't trust anybody else. And in a networked society, you've got to trust people.

To listen the full podcast, and others in the series, visit SaaShimi. Many thanks to Aznaur Midov for producing such a useful resource.

A grey colored placeholder image