The move to SaaS applications built on SaaS is a much more profound shift than the move from on-premise applications to SaaS applications. It’s spawning a new software service economy — and it’s disrupting the software industry.

Written by Greg Olsen, Founder and CTO of Coghead

Imagine that your friend tells you that he has an idea for a new Palo
Alto, Calif.-area restaurant that he wants you to invest in. His pitch goes like
this: The restaurant is all about self-sufficiency. In addition to
actually serving good food, this restaurant will feature the following:

  • All food served will be organically raised and processed on-site
  • Power will be provided by an on-premise power plant
  • Water will be provided by a well-and-rain capture
  • A self-contained waste management system will eliminate the need for a
    sewer hookup

While there are probably some people in Palo Alto that might actually
think this is a good idea, you being of sound mind respond, “Is this a
joke? Why build basic infrastructure like foodstuff production, water,
sewer, etc. when very efficient, cost-effective, ‘pay-as-you-need-it’
options already exist?”

Imagine that your other friend tells you that she has an idea for a new
software application company she wants you to invest in, and that
this company (in addition to actually creating a useful service-based
application) will:

  • Build and manage redundant data centers with a carefully constructed
    custom hardware and software stack
  • Set up an advanced network peering infrastructure for redundancy and
    improved latency
  • Implement a flexible payment system for customers and channel partners

This could also be misconstrued as a joke. Why would a small
application provider spend so much capital, time and energy building
infrastructure when readily available ‘pay-as-you-need-it’ services
exist, such as compute, storage and network infrastructure services (e.g. Amazon’s
EC2 & S3 services), and payment services from Google, Amazon, etc.?

It is possible that specifics of your friend’s application make use of
available service options infeasible, but it is just as likely that your
friend has simply not yet adapted to a service-based infrastructure
reality. There are always seemingly good reasons to continue doing things the way they were done in the past, and transition
always presents challenges. As ironic as it may be, we continue to see
software applications deployed as a service but which fail to use any
service-based infrastructure themselves. They are two basic reasons for
this situation: Change of existing operational services is hard. So is changing people behavior.

Once an application service is deployed, infrastructure changes are
hard to make. Often commitments of capital cannot be undone without very high
switching costs, such as advanced purchases of compute and storage
capacity. Many architectural choices can have lasting ramifications.

For example, if a provider built their application based on the
assumption of very large SMP servers, a proprietary commercial database
clustering approach and vendor-specific HA infrastructure, they would
find it difficult if not impossible to move to a service-based
infrastructure that’s based on generic hardware/software platforms and
horizontal scaling.

Even for a new application service, it’s often hard to find people who
will embrace disruptive infrastructure options. It is almost inherent
in human nature that once we develop a difficult skill we are reluctant
to give up using it — even after simpler and more efficient alternatives
become obvious. Often, people perceive that their livelihood is tied to
the skill and then fear their own obsolescence in the obsolescence of
the skill. The history of software applications provides a rich set of
examples of this phenomenon. At one time, it was common for software
application providers to create their own hardware, operating systems,
networking infrastructure, languages, compilers, user interface
technology, etc. Eventually, successful application providers took
advantage of standard hardware platforms, operating systems and
languages — to the detriment of the many providers that clung to the prior
model. Likewise, vendors that leveraged the Internet and application
servers gained, while many others continued to cling to proprietary
client/server architectures and were the worse for it.

The recent “software-as-service” phenomenon is a particularly
interesting example of disruptive change. SaaS was first seen as a
disruptive force inside of the IT groups of large application users.
Most companies are starting to understand that they would be better off
with less information technology on their premises and more of it
procured as a service over the Internet. Still, however, many within IT
organizations are reluctant to embrace this form of change. (Personally, every time I see an IBM Blade Server commercial during a major sporting event, I’m wondering what percentage of the viewers know what it is,
what percentage of those could actually affect the purchase of one, and
then what percentage of those should actually be buying data center
servers in an efficient universe).

We are now at point where implementors of SaaS capabilities are being
disrupted by newer SaaS capabilities. Services that are built largely
from other services are a reality, and offer many clear advantages. The
types of services that could be used in the creation of new services
span the spectrum, from base infrastructure services to complementary
high-level application services that can be composed or mashed up.
Example services include: compute and storage services; DB and
message-based queuing services; identity management services; log
analysis and analytic services; monitoring and health management
services, payment processing services; e-commerce services like
storefronts or catalogs; mapping services; advertisement services; in
addition to the more well-known business application services like CRM
and accounting.

The move to SaaS applications built on SaaS is a much more profound
shift than the move from on-premise applications to SaaS applications.
The software industry is beginning to display characteristics that
mimic the supply chains and service layering that are commonplace in
other industries like transportation, financial services, insurance,
food processing, etc. A simple set of categories like applications,
middleware and infrastructure no longer represents the reality of
software products or vendors. Instead of a small number of very large,
vertically integrated vendors, we are seeing an explosion of smaller,
more focused software services and vendors. The reasons for this
transition are simple: It takes less capital and other resources to
create, integrate, assemble and distribute useful software

By leveraging service options like Amazon’s EC2 and S3, a
small company can deploy a complex, highly available and scalable
multi-user software application — without huge upfront investments in
hardware or software infrastructure. Likewise, a very small company can
build a simple, narrowly focused service and can cost-effectively sell
it to a mass audience. Neither of these companies would have been possible only a short time ago.

A new software service economy is rapidly unfolding and is causing
disruption in the software industry. Ironically, some of the first
victims of this new economy may be some pioneers of the software-as-a-service movement. Today, many established SaaS application providers
are applying much more of their precious focus and capital to
infrastructure issues than newer competitors that are aggressively
utilizing service-based infrastructure. The self-contained restaurant
and the build-it-all-ourselves SaaS application vendor both have
seemingly good rationales for their chosen paths, but both will
ultimately end up as anachronisms that are left behind by their competition.

  1. Your economic cost/benefit analysis are very appealing to small businesses, but until your company or Amazon for that matter is willing to guarantee SLAs its a niche market play that doesn’t scale. Even worse the concern of IP and data property rights, as Nitin Borwankar elegantly articulated here in a post last week, is just one of many major hurdles in uptake of SaaS.

    Don’t get me wrong I’m grateful for such services as Amazon EC2 and Coghead exist for start-ups to prototype and RAD on them. Though you won’t see non-beta SaaS on Infrastructure as a Service till availability, performance, disaster recovery, and the like are guaranteed. I look forward to that day, and the company that’s willing to provide guarantees and a license that allows derivate works will eclipse anachronistic companies that charge for as-is instability.

  2. Nice Comparison. But I wonder how much time will it take for the big companies to realize this. Even Amazon which provides services like EC2 and S3 are not using these services as they are not tested for huge traffic sites. May be in the future once these services become more stable and reliable we can see a shift but until then there will be no slowing down on infrastructure spending for these big companies.

  3. From the site: “The recent “software-as-service” phenomenon is a particularly interesting example of disruptive change. [...] Most companies are starting to understand that they would be better off with less information technology on their premises and more of it procured as a service over the Internet. Still, however, many within IT organizations are reluctant to embrace this form of change.”

    An excellent point. In 1980, I worked for a school district “data center” that had a huge investment – in hardware and human resources – in “big iron,” an IBM System 370 mainframe, that handled all of the district’s computing needs: report cards, bus schedules, payroll, and so on. When the Apple II and Commodore PET came along, we bought some to use in the vocational classroom in the building. When I wrote a database application for the PET (in BASIC) that maintained the voc-ed class lists, I felt like Galileo suggesting that the earth went around the sun.

    In retrospect, I understand that the high priests of the mainframe were motivated in their denial of the abilities of the new microcomputers not by stubbornness, but by self-preservation. If what I suggested was true, that these “toys” could and would replace their “big iron,” it meant their livelihood was threatened. Now faced with “software as a service” and “cloudware” (which somewhat ironically moves us back in the other direction, from millions of individual applications located on PCs to web applications hosted by huge server farms), the reaction is no different than it was almost 30 years ago.

    A well-written article by Greg Olson; highly recommended to any IT professional or individual PC user.

  4. Change is hard, change is scary – and inevitable | New Tech Heroes | Technology is your friend Thursday, February 14, 2008

    [...] Coghead, a web-based system that allows users to create business applications, writes about "How Not to End Up as an Anachronism." The article describes the resistance to changes in the way we use computers and [...]

  5. Maybe I am missing the context for your example friend’s start-up, but I definitely think that there is more room for infrastructure players than the lone AWS play. Yes there are some companies in each of the categories of compute, storage, payment, etc…, but no one ties them together other than possibly AWS. One could argue that even AWS integration, scaling and management is not trivial and needs improvement. I welcome someone to come in and compete to make it better and cheaper, although I doubt it will be a start-up for scaling reasons. (Looks as if LoudCloud was 5 years too early) And using off the shelf component will be unlikely as even AWS uses custom software and Google admits to building its own servers, Linux kernel and rumored routers.

    I do concur that SaaS built on SaaS will be more disruptive than just the act of moving to the cloud in the first place. But don’t mock those wanting to build infrastructure SaaS until the situation is a lot more mature than what we have today.

  6. Todd,

    I very much agree that there is plenty of room for other base infrastructure players besides AWS, and that competitors will likely not be small startups. I also agree that, in general, current service-based infrastructure offerings including AWS are still not fully mature. I do not think ‘those wanting to build infrastructure SaaS’ should be mocked, but I do think they should think harder about those choices before they make them given the SaaS on SaaS trends that becoming ever more clear.

  7. Although I see the significant benefits of SaaS as an infrastructure alternative, I’m not sure if its entirely cost effective yet for the start-up with no cash. What scares me are the variable costs for traffic, cpu time, etc. At least when I run my own hardware, my own server capacity limits these traffic-driven incremental costs.

  8. I see a few roadblocks on the way to a commodity network software infrastructure nirvana.

    1. sole supplier: right now it’s Amazon or someone much smaller and incompatible. And there are some companies out there that are not willing to use Amazon’s web service for competitive reasons

    2. no standards == no market: if you could seamlessly migrate a project from amazon to joyent or to rackspace or some other provider, then you could be said to have an actual market. If you could take an AMI and run it on your own machinery without needing to modify it, then you would have a standard. Having to dance around with packaging software and different management interfaces for different providers doesn’t fly.

    3. certain core features lacking: right now if you want to do load balancing on EC2 your choices are DNS round robin, or Reverse Proxy, network load balancing at the hardware level isn’t even on the menu, yet it ought to be a standard service from infrastructure providers.

    EC2 and S3 are amazing and cool and Werner Vogels is a rock star for having lead the team that created them; but until there is a common portability standard and multiple suppliers, the market for virtual infrastructure services is not mature.

  9. SaaS does offer speed, scalability and capital efficiency for start-ups, but I’m not convinced that it eliminates lock-in that can hamper growth and innovation at later stages.

    Networking benefited tremendously from the ISO standards that isolated the layers of communication transactions. Huge leaps in innovation, competition, and scaling occurred at the layers of TCP/IP, for example, that were completely independent of the application layer. I’m no expert, but I don’t think it’s trivial to port SQL database transactions between SaaS providers.

  10. Eastwick Communications Client Coverage » GigaOM: How Not to End Up as an Anachronism Thursday, February 14, 2008

    [...] the full post. Coghead, GigaOM, Greg Olsen Share [...]

Comments have been disabled for this post