Commodity hardware has gotten very cheap. Hence it often makes more economic sense to spread the load in the cloud over several cheap, commodity servers, rather than one large expensive server.

Microsoft's Azure data pricing makes this very clear. One Gigabyte of SQL Azure costs about $10 per month. Azure table storage costs $0.15 per GB per month.

The data transfer costs are the same for both. With Azure table storage you pay $0.01 for each 10,000 storage transactions.

To break even with the SQL Azure price you can get about 9,850,000 storage transactions per month. That is a lot of bandwidth!

Another way to look at the cost is to suppose you need only 2,600,000 storage transactions a month (1 a second assuming an equal time distribution over the day). That would cost you only $2.60. That means you could store almost 50 GB worth of data. To store 50 GB worth of data in SQL Azure would cost about $500 / month.

If you don't need the relational model, it is a lot cheaper to use table or blob storage.

One way to approach the different architectural implications is to look at the various vendor offering and see how they match to the various application types.

You can divide the cloud vendors into four categories, although one vendor might have offerings in more than one category:

Platform as a Service providers
Software as a Service providers
Application as a Service providers
Cloud Appliance Vendors

The Platform as a Service providers attempt to provide a cloud operating system for users to build an application on. An operating system serves two basic functions: it abstracts the underlying hardware and manages the platform resources for each process or user. Google App Engine, Amazon EC2, Microsoft Azure, and Force.com are examples of platform providers.

The most restrictive platform is the Google App Engine because you program to the Google API which makes it difficult to port to another platform. One the other hand, precisely because you program to a specific API, Google can scale your application and provide recovery for a failed application.

At the other extreme is Amazon. Amazon gives you a virtual machine which with you can program directly against the native OS installed on the virtual machine. This freedom comes with a price. Since the Amazon virtual machine has no knowledge about the application you are running, it cannot provide recovery or scaling for you. You are responsible for doing that. You can use third party software, but that is just a means of fulfilling your responsibility.

Microsoft tries to achieve a balance between these two approaches. By using .NET you have a greater degree of portability than the Google API. You could move your application to an Amazon VM or even your own servers. By using metadata to describe your application to the cloud fabric, the Azure infrastructure can provide recovery and scalability.

The first architectural dimension (ignoring for a moment the relative econonmics which will be explored in another post) then is how much responsibility you want to take for scaling and recovery vs. the degrees of programming freedom you want to have. Of course the choice between the Google API and Microsoft Azure might come down to the skill set of your developers, but in my opinion, for any significant application, the architectural implications of the platform choice should be the more important factor.

One of my clients, ITNAmerica has become a Microsoft case study for the idea of software + services. The idea behind software + services is that software should run where ever it makes sense: in the cloud, on the desktop, or on a mobile device, not just in a thin client such as a browser.

Latency, bandwidth limits, and the need for software to  work if the connection to the cloud disappears makes this a logical approach.  Anybody who has tried to get a cell phone signal should understand the issues about continual connectivity.

Curt Devlin, a Microsoft evangelist, demonstrates another reason why this approach makes sense. It makes the transition to a cloud provider such as Azure much simpler.

If you want some further ideas on how to take a software + services application to a cloud platform. Check out my recent ARCast on "Software + Services in the Cloud."

The application delivery scenarios focus around software as a service. Software as a service applications fall into three varieties: pure service, and software + service, hosted application.

The hosted application scenario is similar to hosted application delivery. Examples are SalesForce, or Hosted Microsoft Exchange. People provide or buy an application that runs in the cloud. At the other extreme is the pure service play. Providers create web services (SOAP or REST based) that provide services used by other applications. Examples are credit card approvals, or certain loan applications. Applications written by third parties use this software to compose their applications in conjunction with their own software. Then there is the mixed play. Providers create both web applications and web services to be used by third parties. These applications consume the same web services that are available to others to build their own applications. This is often done to allow the provider to share the web services among various offerings, or because they need to boot strap the application marketplace. The need for rich clients does not necessarily disappear here. If applications (such as emergency services) have to run with loss of internet connectivity, stand alone apps may be necessary with synchronization software used when connectivity is re-established. Transactional queuing is not enough here because substantive work has to be done by the rich client app when connectivity is absent.

Internet scale is the last class of application. The first scaling factor is number of users. In order to achieve such scale you may to use cloud features such as tables (Google Big Table, Azure Tables, Amazon Simple DB) instead of or in addition to relational databases. Note that transactional guarantees are often impossible to make here. The second scaling factor is geographic distance. If your clients are geographically separated by enough distance, the latency caused by the speed of light in fiber optic cable actually matters. You may have to use the cloud features mentioned previously to achieve the responsiveness for writeable data because transactions, especially distributed transactions are not feasible to achieve scalability.

The next post in the series will start to discuss the architectural  implications of these different types of applications.

Cloud computing is utility computing. No up front commitment required. You buy only what you need, and when you do not need it any more you do not pay for it.

There are three basic cloud computing scenarios: infrastructure scenarios, application delivery scenarios, and scaling scenarios. These scenarios are not independent, one or all of them can come into play.  Each, however, has different technological implications.

The three basic scenarios are: infrastructure, application delivery, or the need to reach internet scale.

Fundamentally, cloud computing is a software delivery platform. Are the economics of working with the cloud cheaper than doing it yourself? Doing it yourself could mean self-hosting, or traditional delivery of desktop software. Self-hosting could be in your own data center, or in a hosting facility.

Not needing to build to your peak capacity drives the infrastructure scenarios. This is not an all or nothing proposition.

Some small and medium sized companies may decide they do not want to run their own data centers. The savings in terms of not having to buy machines and pay employees is enormous. This money could be put to use in building better applications. This might be the entire compute infrastructure, or just running an email server.

Other companies may have an occasional need for massive computation. Say you have to do a stress analysis of a new airplane wing, or a geographical routing of a complicated delivery, decide among alternative new financial models, or even a human genome search. Any of the classic grid computations fall into this category. Your existing infrastructure is just fine, but for these not every day scenarios (they might actually be frequent) it makes sense to rent space in the cloud to do the computations.

A related scenario is cloud-bursting. You can handle your everyday computing demands, but occasionally you get a burst of orders that overwhelms your system. Ticket agencies are a classic example when tickets for a popular event first go on sale. So are stores around the holidays. Here you use the cloud to handle the overflow so that people wanting to order do not get unresponsive web pages, or busy signals on the telephone.

Small divisions in large companies may find the cloud appealing for prototyping, or even developing certain applications. Their central IT may be unresponsive or slow to respond to their needs. It is well within the capacity of a departmental budget to rent space in the cloud.

The next post will explore the other two scenarios, and look at how the various vendor options would meet your needs.

https://www112.livemeeting.com/cc/microsoft/view?id=M7GT9D

Want to provide some input to Microsoft?

Here is a blog entry that contains a link to a survey that would help them decide on priorities for providing cloud security guidance: http://blogs.msdn.com/jmeier/archive/2009/08/04/cloud-security-survey.aspx.

The post explains the rationale behind the survey.

I just did an interview on .NET rocks about cloud computing.

We covered a whole bunch of topics including:
                     what is cloud computing
                     comparing the various offering of Google, Force.com, Amazon, and Microsoft
                     the social and economic environment required for cloud computing
                     the implications for transactional computing and the relational model
                     the importance of price and SLA for Microsoft whose offerring is different from Amazon and Google
                     the need for rich clients even in the world of cloud computing.

One of the big advantages of cloud computing is its utility computing model. Customers can use as much compute power or as little as they want without paying for what they do not need. Normally, most data centers have to be built for peak demand, with the servers unused when they are not needed.

Utility computing is based on the electric utility model. While this comparison has a lot of merit, there is one particular part of the analogy that really does not work.

Data are not electrons.

If someone steals some of your electric power by diverting it, you can get replacement power.  If one part of the country's electric demand exceeds its generating ability, it can get power from another part of the grid. One electron is as good as another.

Data has identity, latency, and relationships to other pieces of data.

If someone steals your data, another piece of data cannot take its place. if your data is stolen, or even delayed it, can aversely affect you. Depending on your resolution of the CAP Theorem dilemma, your replication strategy might leave you with a window of vulnerability for data loss.

Curiously, the argument has been made that the utlity computing model makes denial of service attacks unfeasible because the economics of trying to get enough bot driven computers to assualt a hugh data center is prohibitive. Sooner or later, somebody is going to try to get the servers of one data center to attack the servers of another data center. Hopefully, the software that monitors the transactions would realize that somebody is exceeding their credit limit.

It's time for me to be interviewed on .NET Rocks again!

Carl and Richard will interview me about Cloud Computing. The interview will be published on June 30 at http://www.dotnetrocks.com/.

Based on my previous show (and related DNR TV segments) it will be a lot of fun to do and to listen to.

Many people have misconceptions about cloud computing. For example, applications do not have to be built so they are all in the cloud. You can put the application in the cloud (to handle parallel computation), and have the database in your enterprise. I was interviewed at TechEd about some of the misconceptions about computing in the cloud.  Other misconceptions discussed include what size business is right for the cloud, the role of the browser, guaranteed connectivity, and cloud security.

Here is my Tech Ed podcast about how small businesses and small business units can benefit from Cloud Computing: http://www.msteched.com/online/view.aspx?tid=a4377dcf-ed90-4872-8d45-ec5108be118e.

I cover some of the material discussed in yesterday's post, but there is also some new content.

Small or medium sized companies can have the advantages of being able to act as a big company while maintaining the advantages of being small.

A hosted solution has many advantages.

You no longer need the staff, or have to spend money on installing and upgrading software on your clients' machines.  Your customers and clients can use your application anywhere, not just on their office computers.  If you provide services as well as an application, third parties can easily use your solution as part of their offering.  Sometimes these services can be used in your own applications such as portals, or future applications. Perhaps your customers can extend your application making it more valuable to them. Having your application in the cloud means that your intellectual property (your secret sauce) is better protected because it is not in the hands of your users.

All these arguments also apply to small business units within a large enterprise.

Nonetheless, small businesses very often do not have the financial ability to economically run, or even rent a significant hosted application solution beyond a small scale web application.

Cloud computing offers a way out of the dilemma.

Cloud computing offers businesses a utility model for computation. Host your application on a cloud platform and you pay only for what you use. With minimal initial investment, you can scale up or down as your customers use more or less of your application or services.

With many cloud vendors (Amazon being a major exception) you do not even know on what infrastructure your machine runs on. Scaling and failover happen in those environments with minimal work on the client's part.

Clearly the cost and reliability of the cloud provider is crucial. Google's most recent outage shows that this is not a unreasonable fear. Private IT centers also have had their outages, but they are not made public.

Microsoft, Amazon,  Google and others are spending huge amounts of money to build cloud data centers. Clearly they see the opportunity.

Right now many large companies already have data centers that can offer cheaper compute power than the current generation of cloud providers. This will eventually change.

But right now, small companies, start-ups, and other similar organizations should think about cloud computing for their hardware infrastructure.

I have uploaded the slides and code for my talk on Windows Azure at the Microsoft MSDN day in Boston on January 22.

The talk was a combination of slides from several PDC talks with some of my own additions. I went through the fundamental architecture of the Azure cloud operating system and the basic elements of the Azure cloud services (i.e. Identity, Workflow, Live, SQL Data Services).

I did two demos. The first was a simple thumbnail generator. It illustrated a simple, scalable architecture using web roles and worker roles that used the primitive Azure operating system storage for blobs and queues.  It also demonstrated how you model and configure a cloud application. The second, using the SQL Data Services, demonstrated how to integrate a non-cloud application (on a desktop or server) with the cloud. The app used a variety of industry standard mechanisms (WS*, REST, HTTP Get) to create and query data.

I will be speaking at VSLive! San Francisco on February 25 on "Advanced Topics in Windows Workflow Foundation".

The conference will be at the Hyatt Regency Embarcadero from February 23-27. Workshops are offered on Feb 23 and 27. The conference sessions are on Feb 24, 25 and 26. If you register with promo code NS9F20 you will receive a $500 discount off the price. The event web site is vslive.com/2009/sf.

There is some great content that covers ALM and Development Tools, .NET, Data Management, Infrastructure, Rich Clients, Distributed Systems, and Web Development. I hope to see you there.

At the PDC Microsoft announced its answer to Amazon and Google's cloud computing services.

This answer has two parts: the Azure platform and hosted applications.  Unfortunately people confuse these two aspects of cloud computing although they do have some features in common.

The idea behind Azure is to have a hosted operating systems platform.  Companies and individuals will be able to build applications that run on infrastructure inside one of Microsoft's data centers.  Hosted services are applications that companies and individuals will use instead of running them on their own computers.

For example,  a  company wants to build a document approval system. It can outsource the infrastructure on which it runs by building the application on top of a cloud computing platform such as Azure.  My web site and blog do not run on my own servers, I use a hosting company. That is an example of using a hosted application.

As people get more sophisticated about cloud computing we will see these two types as endpoints on a continuum. Right now as you start to think about cloud computing and where it makes sense,  it is easier to treat these as distinct approaches.

The economics of outsourcing your computing infrastructure and certain applications is compelling as Nicholas Carr has argued. 

Companies will be able to vary capacity as needed. They can focus scarce economic resources on building the software the  organization needs, as opposed to the specialized skills needed to run computing infrastructure.  Many small and mid-sized companies already using hosting companies to run their applications. The next logical step is for hosting on an operating system in the cloud.

Salesforce.com has already proven the viability of hosted CRM applications.  If I am a small business and I need Microsoft Exchange,  I have several choices. I can hire somebody who knows how to run an Exchange server. I can take one my already overburdened computer people and hope they can become expert enough on Exchange to run it without problems. Or I can outsource to a company that knows about Exchange,  the appropriate patches, security issues, and how to get it to scale. The choice seems pretty clear to most businesses.

We are at the beginning of the cloud computing wave, and there are many legitimate concerns. What about service outages as Amazon and Salesforce.com have had that prevent us from accessing our critical applications and data? What about privacy issues? I have discussed the cloud privacy issue in a podcast.  People are concerned about the ownership of information in the cloud.

All these are legitimate concerns. But we have faced these issues before. Think of the electric power industry. We produce and consume all kinds of products and services using electric power. Electric power is reliable enough that nobody produces their own power any more. Even survivalists still get their usual power from the grid.

This did not happen over night. Their were bitter arguments over the AC and DC standards for electric power transmission. Thomas Edison (the champion of DC power) built an alternating current electric chair for executing prisoners  to demonstrate the "horrors" of Nikola Tesla's approach. There were bitter financial struggles between competing companies. Read Thomas Parke Hughes' classic work "Networks of power: Electrification in Western society 1880-1930". Yet in the end we have reliable electric power.

Large scale computing utilities could provide computation much more efficiently than individual business. Compare the energy and pollution efficiency of large scale electric utilities with individual automobiles.

 Large companies with the ability to hire and retain infrastructure professionals might decide to build rather than outsource. Some companies may decide to do their own hosting for their own individual reasons.

You probably already have information in the cloud if you have ever used Amazon.com. You have already given plenty of information to banks, credit card companies, and other companies you have dealt with. This information surely already resides on a computer somewhere. Life is full of trust decisions that you make without realizing it.

Very few people grow their own food, sew their own clothes, build their own houses, or (even in these tenuous financial times)  keep their money in their mattresses any more. We have learnt to trust in an economic system to provide these things. This too did not happen overnight.

I personally believe that Internet connectivity will never be 100% reliable, but how much reliability will be needed depends on the mission criticality of an application. That is why there will always be a role for rich clients and synchronization services.

Hosting companies will have to be large to have the financial stability to handle law suits and survive for the long term. We will have to develop the institutional and legal infrastructure to handle what happens to data and applications when a hosting company fails. We learned how to do this with bank failures and  we will learn how to do this with hosting companies.

This could easily take 50 years with many false starts. People tend to overestimate what will happen in 5 years, and underestimate what will happen in 10-15 years.

Azure, the color Microsoft picked for the name of its platform, is the color of a bright, cloudless day.  Interesting metaphor for a cloud computing platform. Is the future of clouds clear?

"Software + Services" is Microsoft's representation of what a large part of the future of computing is going to be. Microsoft, however, has not done a great job of explaining what "Software + Services" is.

Based on what I have read and heard, let me try to explain it as I see it.

The fundamental question that one has to ask is "Where does computation happen?"

The obvious answer to everyone today is: "Everywhere".

 We compute on mobile devices, appliances, desktops and laptops, and remote computers. We communicate with text and voice.

Everybody understand this. The key question is: "Why?"

I think the answer is because "Hardware is cheap, and data is expensive to move."

The late Jim Gray did an analysis¹ of the economics of distributed computing. His analysis came to two conclusions:

1. Put the computation near the data. Unless you have something that is very compute intensive, it is much cheaper to not move the data.
2. If you need data from multiple sites, push the processing closer to the data source by filtering the data early.

The assumption here is that telecommunication prices drop slower than Moore's Law.  So far this has always been the case.

The natural conclusion is to do the computation where the data naturally resides. In other words: Do what makes sense. Some things will be in the cloud, some things will still be on the desktop. As long as Internet connectivity is not ubiquitous, and not always connected, you may have to cache data somewhere. Depending on the mission criticality of your application, a few seconds could be a long time.

As Ray Ozzie put it in his MIX Keynote, we live in a "World of small pieces loosely joined."

Software + Services means some things will be services in the cloud, others will be software as we know it today.  That includes mobile devices and appliances that we are learning to love and hate, just as we have always done with traditional software.

1. MSR-TR-2003-24 "Distributed Computing Economics"