How Not to End Up as an Anachronism
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 capabilities.
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.
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.
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.
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.
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.
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.
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.
I see a few roadblocks on the way to a commodity network software infrastructure nirvana.
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
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.
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.
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.
One of the posts above discusses SLA’s. I built a SaaS company. Bottom line SLA’s don’t add up to crap. Industry SLA’s are just fluff marketing material. What happens when your Microsoft Exchange server goes down? What happens when a backhoe breaks the fiber optic line in front of your building? What happens when your cell phone drops a call?….. Where’s the SLA in those scenarios? Do you think that AT&T is going to reimburse you for downtime, NOT! Best case scenario you can break your contract and go buy or subscribe to another offering with the same SLA’s.
As a buyer of these services you have to measure ROI. PERIOD!!!! It’s not a matter of privacy or security. I receive my pay-stub electronically? I view my financial information online? I would argue that a person will weigh this much more than the business offering.
SaaS is about: 1) ROI 2) Selling to the CFO not the IT guy/gal 3) Scalability 4) Having 24×7 Presence 5) On-demand features add on functionality (i.e. CRM + IP Telephony) 6) Peace of mind…. well maybe this last point is a stretch:)
Ubay: Amazon does run their services internally.., their services are utilizing their excess storage and computing capacity they must maintain to scale their operations. By selling their services they are able to scale their infrastructure at a much greater rate, in a much more cost effective manner.
Ryan: These services.., Amazon being the main player.., are very cost effective for startups. Being able to have cheap redundant storage, and processing power that you can scale out on-demand is a great thing. There is no “variable pricing” on Amazons services.., you pay a flat fee per gig storage, or time based for EC2.
“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.?”
That has to hurt just a little bit in light of the headline at the top of this site: “Amazon S3 Storage Service Goes Down, Still Not Up”. That’s why people want their own services sometimes. Do you think anybody is going to get compensation for S3 going down? I doubt it. If it was your own infrastructure that went down you could probably get it up much faster.
The organic restaurant is a great example. Here’s a place with a 0 carbon footprint — a great selling point to the greenies. Yeah it fails to leverage existing pay as you go options, but when those options don’t match what you need, or do it in a wasteful, half-assed way, and you can do it better, why not do it yourself if you can get your customers to pay for it? Just make sure you don’t include a parking lot, otherwise you’re a hypocrite.
Well, he would say that, wouldn’t he…
Meanwhile, in a beautiful irony, S3’s doing a good impression of a whore’s drawers (maybe “Christine Keeler’s drawers” would be a more apt analogue). And, just at a guess, I’m betting that Amazon engineers will be focusing on a) getting those bits of S3 that Amazon depends on up and stable and then b) getting home for the weekend. If that doesn’t sort out the bits relied on by the Uncov fodder then hey, sucks to be them. After all, how much service do you expect for $.15/GB/month…
Greg:
Adapt or die. Simple as that. Oh, and have a backup plan, just in case Amazon.com goes down with all your SAAS data and software on it.
Will the real SaaS please raise their hand -
In all the noise about the evolution from enterprise software to SaaS, I think the real value of SaaS gets lost. While this David and Goliath (SaaS vs. Enterprise Software) story is interesting, the real value is that the, until now, unserved mid-market can now access these sophisticated tools within their budgets. With a SaaS model there is typically no need for IT involvement, there is no deployment and no need for a professional services team to be onsite for 3 months. There was, in the past, no question of on premise vs. hosted or redundancies in data – the mass target market had the option of paper, MS Excel, or a $99 app from CompUSA as the options, now they have a fully featured application at their finger tips – the same their much larger competitors may already have. SaaS is like being able to afford a Porsche on a rental model (no maintenance Required but you), who cares if it’s only a Boxter (do you really need the Carrera GT that goes 300 mph – where would you drive it?).
Risk management is always danced around. But I feel that the risk in outsourcing to a best-of-breed service will almost always outway the risk of managing the same service in-house.
@Alex: Except that I prefer risk management as #1, absolutely correct, especially in light of Amazon’s downtime after this article came out. Your take on SaaS SLAs didn’t even mention how losing a key employee or two before a less disruptive event can be just as bad.
@Troy: People say they want accountability, what they really want is results and communication. Amazon’s results are fine. Their communication needs to improve. I like Alex’s list for evaluating results, starting with ROI and Scalability. Look at what happened to Friendster, with great financing and great people: poor site performance killed their lead.
No one wants poor performance in-house that could be improved on by going with SaaS.
@Suaad Sait: The featuresets SaaS makes available are remarkable, but value still needs to be measured as ROI, as Alex points out.
Who looks like a real dick now Greg, that S3 has been down for a few hours. Some CTO you are to think a SLA with 99.9% of uptime is something good!
This discussion begs the questions of Intellectual Property (IP) and core versus non-core. These two factors are significant drivers for any vendor who wants to bring a web-based service to market. The core versus non-core argument goes something like this: outsource what you can, keep what’s core to your intellectual property.
We are already seeing that some services, such as storefront and monitoring, are clearly non-core. Here’s the question for SaaS vendors: What do you offer that’s unique and is it yours?
[...] 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 [...]
[...] the full post. Coghead, GigaOM, Greg Olsen Share [...]
[...] “GigaOM: How Not to End Up as an Anachronism“: There are always seemingly good reasons to continue doing things the way they were done in [...]
[...] How Not to End Up as an Anachronism – GigaOM move to SaaS applications built on SaaS is a much more profound shift than the move from on-premise applications to SaaS applications… It takes less capital and other resources to create, integrate, assemble and distribute useful software capabilities. (tags: saas webservices infrastructure itmanagement saas-transformation) [...]
[...] We may be approaching the end of the road for established SaaS vendors — like Salesforce.com, NetSuite, Concur, Taleo and RightNow — who build their own data center infrastructure instead of consuming infrastructure as a service. That’s the message posed in a guest column on GigaOm titled How Not to End Up as an Anachronism. [...]
[...] How Not to End Up as an Anachronism – GigaOM Why would a small application provider spend so much capital, time and energy building infrastructure when ‘pay-as-you-need-it’ services exist, such as compute, storage and network infrastructure services, and payment services from Google, Amazon, etc (tags: webservices saas ec2) [...]
[...] un article publié sur GigaOM, Greg Olsen (fondateur de coghead.com) pose une question intéressante : les [...]
[...] post info By deliveredinnovation Categories: Delivered Innovation and Platform as a Service Tags: Software as a Service, Platform as a Service, Cloud Computing, Delivered Innovation, SaaS, PaaS, Coghead How Not to End Up as an Anachronism [...]
[...] How Not to End Up as an Anachronism [...]