Skip to main content

Defining Cloud Computing

Posted by richunger on September 24, 2008 at 4:23 PM PDT

Okay, so what is “cloud computing”?

Much like “rich internet application” or “service-oriented application”, the terminology has been co-opted by so many companies as to almost completely lose its meaning. But, since this is my blog, I’ll define cloud computing as it pleases me.

As a useful, functional definition, I think cloud computing should cover any service that allows individuals or companies to change the primary home of their data from being self-hosted to being “in the cloud”.

That’s it. It’s the outsourcing of your data.

Of course, that implies some API or application to access your data. Some simple examples:

Webmail: Gmail, Hotmail, and Yahoo mail hold users’ email on their own servers, and (MS Exchange notwithstanding) many companies are moving away from self hosted IMAP servers.

Online office apps: Google Docs, Zoho, etc. This one should be obvious.

Personal Finance: Mint.com and it’s competitors attempt to replace Quicken and MS Money. Your financial data is stored (with appropriate privacy and security safeguards) on their servers. It’s accessible from anywhere, updated automatically, and you get the benefit of everyone else’s aggregated data, to see where you fall, for example, compared to the average food dollars spent per month.

CRM: If individuals now trust the cloud with their personal financial data, it’s only because corporations led the way. Salesforce.com holds the sales, marketing, and financial data for lots of companies, big and small. I’m not sure which ones I’m allowed to talk about, so I’ll leave out the examples. Suffice to say, the market adoption hurdle has been overcome. CTO’s have realized that Salesforce.com has better uptime than their own IT departments, and CFO’s have realized that security breaches are at least as likely with disgruntled IT employees, and we’re easier to sue.

Also, if you make, say, canned fruit, why do you have employees who are experts in the minutiae of Oracle administration? It’s much cheaper and easier to buy that as a service.

Now, these examples are all single applications (or suites of applications). Adoption is strong, and the cloud computing market is moving into a new phase.

The cloud computing platform.

Okay, so we have a workable definition of cloud computing: it’s the outsourcing of data. But so far, we’ve only examined data associated with certain specific applications. Most companies have all kinds of data in their Oracle databases, Excel spreadsheets, and custom applications. None of this fits neatly in existing off-the-shelf apps.

This is why custom app development is where most software development is really done. This is why SAP has been so successful for so long.

So, if we’re interested in the benefits of outsourcing our data, we need a way to write custom applications to access it. We could write a desktop app or self-hosted webapp to talk to the data over SOAP or REST. But, as any CS major will tell you, programs and data are really the same thing. Those programs, too, can live in the cloud.

There are several approaches:

Amazon.com’s EC2 and S3: Basically, you outsource the hardware management, and provision your own virtual machines. Very flexible. Gives you lots of control, but you still need Oracle admins, system admins, and application development is done basically the same way it always has been.

Google App Engine: The developer comes in at a higher level here. You must use their Python interface to code the app. However, you’re not administrating the machines (or VMs). You’re not running the database. You have access to some pre-existing data (like Google user accounts for authentication). For the most part, you’re still coding your application from scratch.

Salesforce’s Force.com: Here, the developer comes in at an even higher level. Basically, you’re getting our CRM application (or a subset of it, depending on your license), and a bunch of hooks to extend it. Instead of Java or Python, you’re using Apex, which is a DSL (domain specific language) for the Force.com cloud, with syntax familiar to anyone accustomed to Java (except it’s got properties!). You can create your own pages with a JSF-like template engine called VisualForce, with Apex-written controller classes.

As with Google App Engine, you’re not administering machines, or a database. You have access to a much wider set of data (a whole pre-built schema with common objects for the enterprise, users, profiles, and a fully fleshed out permissions hierarchy). Sure, the focus of the platform is much more narrow, but if you’re writing things like intranet apps, the development cycle is much, much shorter. Our basic platform tutorial takes you through building a full HR recruiting app in a single session. And integrations are extremely simple. Creating your own SOAP services in the cloud is as easy as annotating your Apex methods with the webservice keyword. Our customers are writing and deploying apps in a few weeks which would take many months to do on a traditional self-hosted app server.

PaaS

The concept is marketed as “Platform as a Service”. There are obvious benefits, like not having to be responsible for backups or uptime. There’s more location independence, and cloud solutions tend to be cheaper, quicker and easier than self-hosting.

Drawbacks? Well, there are privacy risks, some loss of control, and there’s definitely a discussion to be had about openness. I’ll get to that one in another post.

Overall, it’s bound to be compelling for a certain subset of the types of apps currently being written in a self-hosted, Java app server environment. I’ve seen some of the stuff our customers are writing, and it’s incredible to me how much more code it would be on a self-hosted platform.

Comments

Certainly, Salesforce.com's customers are accepting that risk by using the service. However, I'd argue that the scenario where SFDC fails will almost certainly leave the actual service in the hands of a buyer like Google or Oracle. The lights wouldn't just go off. There's too much revenue being generated by it for it not to be appealing to someone. Yes, Java will continue to work in any event. The question is how much is that absolute security worth to your company? Are you willing to pay twice as much? 5 times as much?

Let me play devil's advocate for a second and look at the risks of salesforce.com. What if the company goes under? If Sun goes under, Java is still working. Below is a list taken directly from the annual report. Thanks, Thomas Risks Related to Our Business and Industry Defects or disruptions in our service could diminish demand for our service and subject us to substantial liability. Interruptions or delays in service from our third-party Web hosting facilities could impair the delivery of our service and harm our business. We rely on third-party computer hardware and software that may be difficult to replace or which could cause errors or failures of our service. If our security measures are breached and unauthorized access is obtained to a customer’s data or our data, our service may be perceived as not being secure, customers may curtail or stop using our service and we may incur significant legal and financial exposure and liabilities. If our on-demand application service is not widely accepted in markets where we have few customers, our future growth and success will be limited. Efforts we are making to expand our service beyond the CRM market may not succeed and may reduce our revenue growth rate and cause us to incur additional liabilities. The market in which we participate is intensely competitive, and if we do not compete effectively, our operating results could be harmed. Our quarterly results can fluctuate and if we fail to meet the expectations of analysts or investors, our stock price and the value of your investment could decline substantially. Because we recognize revenue from subscriptions for our service over the term of the subscription, downturns or upturns in sales may not be immediately reflected in our operating results. If we experience significant fluctuations in our rate of growth and fail to balance our expenses with our revenue forecasts, our results could be harmed and our stock price may decline without advance notice. As a result, we expect that our operating results may fluctuate significantly on a quarterly basis. Our recent revenue growth rates may not be sustainable and may decline in the future. We believe that period-to-period comparisons of our operating results may not be meaningful, and you should not rely upon them as an indication of future performance. The market for our technology delivery model and on-demand application services is immature and volatile, and if it develops more slowly than we expect, our business could be harmed. We cannot accurately predict customer subscription renewal rates and the impact these renewal rates will have on our future revenue or operating results. Our future success also depends in part on our ability to sell additional features and services, more subscriptions or enhanced editions of our service to our current customers. This may require increasingly sophisticated and costly sales efforts that are targeted at senior management. If these efforts are not successful, our business may suffer. Our growth could strain our personnel resources and infrastructure, and if we are unable to implement appropriate controls and procedures to manage our growth, we may not be able to successfully implement our business plan. As more of our sales efforts are targeted at larger enterprise customers, our sales cycle may become more time-consuming and expensive, we may encounter pricing pressure and implementation challenges, and we may have to delay revenue recognition for some complex transactions, all of which could harm our business and operating results. Periodic restructurings of our sales organization can be disruptive and may negatively impact our revenues. If we are not able to develop enhancements and new features to our existing service or acceptable new services that keep pace with technological developments, our business will be harmed. Any failure to protect our intellectual property rights could impair our ability to protect our proprietary technology and our brand. We have been and may in the future be sued by third parties for alleged infringement of their proprietary rights. If we fail to develop our brands cost-effectively, our business may suffer. Failure to adequately expand our direct sales force and develop and expand our indirect sales channel will impede our growth. Our business could be adversely affected if our customers are not satisfied with implementation and customization services provided by us or our partners. Sales to customers outside the United States expose us to risks inherent in international sales. Evolving regulation of the Internet may affect us adversely. Privacy concerns and laws or other domestic or foreign regulations may reduce the effectiveness of our solution and adversely affect our business. Our business is subject to changing regulations regarding corporate governance and public disclosure that have increased both our costs and the risk of non-compliance. We are dependent on our management team and development and operations personnel, and the loss of one or more key employees or groups could harm our business and prevent us from implementing our business plan in a timely manner. Because competition for our target employees is intense, we may not be able to attract and retain the highly skilled employees we need to support our planned growth.

This is really a great post, Rich. I had some problems with clear definitions of this stuff, but now I think I'm ok.