Despite the obvious advantages of PAAS over IAAS, very few enterprises would see economic benefit in redesigning their applications for a PAAS platform. IAAS provides a means to allow them to use their already virtualized environments on someone else’s hardware. Ultimately, cloud computing is about economics. Even those moving to PAAS, for the most part, are treating it as a hosting platform. They are looking for a cheaper way to host, which as I have argued elsewhere is usually not the case.

In both cases, what people are doing is outsourcing the datacenter.

To get the true benefits of cloud computing, whether through IAAS or PAAS, you have to design explicitly for that platform. I have discussed this in many past blog posts. You have to design explicitly for failure, and you have to recognize that you are building a distributed system. Over the long term this approach will bring sustained success.

IAAS as currently applied is a dying niche. Of course any evolutionary extinction takes time. The long time span allows it to be unnoticed, or even if noticed, most people feel it will not affect them. Of course sometimes dynamic changes occur. Ask the dinosaurs, or even the railroads or minicomputer companies. See how the companies that compose the Dow Jones averages have changed over the past 100, 50, 30, or even 10 years.

Companies continue to do things the way they have always done until a successful company creates a new fad in corporate philosophy. Companies then run to become blind followers. One classic example is Deming’s work on modern manufacturing. Although he lived in the US, it was not until the Japanese had success with it that US industry started to adopt his ideas.

Someday, somewhere, somebody is going to build a widely successful company using PAAS. Then, everyone, like lemmings, will run to emulate them. The irony is that some will run to do it even if it makes no economic sense for them.

People get confused and try to reconcile what "cloud" means in the terms public cloud and private cloud. To me they are contranyms. Those are words that are spelled the same but have two entirely different meanings.

For example, the word "fast". It can mean to move rapidly. The runner ran fast. It can also mean to be held tightly. The mast held fast to the ship during the storm. Another example is "clip". He clipped the papers together. He clipped the coupons from the newspaper.

The world cloud is being used in two different ways. In public cloud, the term cloud refers to utility computing which is effectively massively scalable. In private cloud, the term cloud refers to a virtualized computing environment which is not massively scalable.

In order to build robust cloud applications, a client that calls a service has to handle four scenarios:

A partial success occurs when a service only accomplishes part of a requested task. This might be a query where you ask for the last 100 transactions, and only the last 50 are returned. Or the service only creates an order entry, but does not submit the order. Usually a reason is supplied with the partial success. Based on that reason the client has to decide what to do next.

Transient failures occur when some resource (like a network connection) is temporarily unavailable. You might see this as a timeout, or some sort of error information indicating what occurred. As discussed in a previous post , continually retrying to connect to a transient resource impedes scalability because resources a being held on to while the retries are occurring. Better to retry a few times and if you cannot access the resource, treat it as a complete failure.

With failure, you might try another strategy before you treat the resource access as a failure. You might relax some conditions, and then achieve partial success. You might access another resource that might be able to accomplish the same task (say obtain a credit rating) albeit at greater cost. In any case all failures should be reported to the client. You can summarize this responsibility in this diagram:

Bill Wilder helped me formulate these thoughts.

We have been talking about cloud failures. How likely are they?

Some outages occur all the time. Even with the excellent reliability of hardware, a cloud data center has an enormous number of components. Something is always failing. Cloud data centers are built to detect failure, and move applications to working hardware, and restart them. They have failure zones so that instances of the same service are kept on different sets of hardware.

What about other kinds of outages?

Amazon and Windows Azure have had interruptions in service, some longer than others. There could be major power outages such as in the Northeast United States in 1965 that left people without power for up to 12 hours. In 2003 there was a major power outage in the Northeastern and North central US as well as Ontario, Canada. The Japanese tsunami had a similar effect. Many smaller outages occur after storms. Even if a data center remains, external Internet connections might be interrupted. In 2009 Google had a major outage in Asia caused by a configuration error that caused problems even in the United States and Europe. The problem was analogous to the cause of the 1965 Northeast US power failure.

As we have discussed in previous posts, any software or service that you depend on is a possible source of an outrage, including the Internet itself. You don’t even need an outage; all you need is for a service to become less responsive. Remember when Michael Jackson died? It was difficult to get to any web site, because there was not enough bandwidth to accommodate everybody’s surfing to find out the news. It was the largest self-inflicted denial of service attack ever.

Are these outages really rare?

As we found out with the financial sector, black swan events can happen. Random events do occur. Small probability events happen. Kahneman and Tversky demonstrated that people reason about probability poorly. While this can be acceptable behavior with regard to personal decisions, it is very questionable when it comes to estimating the probabilities of rare engineering events

You cannot assume that any connection to a distributed service will always be available.

Netflix’s continual availability during the April 2011 Amazon outage is now legendary. The reason for their success was because they assumed failure was possible. They had stateless services. They restricted the use of relational data to where it was really necessary so they could switch to a hot standby. They degraded gracefully, only keeping alive services that were really necessary. You might not have been able to get your personalized movie list, but you could still find and play movies. They had enough excess capacity to deal with transient failures, and shifting loads.

Assume the rare can occur, because it will.

To avoid a single point of failure you needed to have redundancy.

There are several power lines between a power station and a customer. When an overload is detected by a circuit breaker, power can be rerouted along another line. Each individual line is normally run at reduced capacity so it can handle the increased load.

Redundancy, however, introduces problems. Business applications have state. One electron is as good as another and can be easily rerouted; application state is tied to particular users, sessions, or transactions. I need to access parts of my current order. If the network connection I am on gets broken, substituting someone else's order does not work. Parallel processing of mathematical algorithms (such as MapReduce, or multi-threaded versions of Linq) cannot solve this problem.

You need to remember information about your users, or what products are on order. Some of this data changes rarely if at all; some of this data changes dynamically. Some of this data is very valuable, some of it is not. In a non-cloud application you might use data base mirroring. But you pay a performance penalty for a database mirror because the transaction must commit on both the original and the mirror. Imagine the cost (latency and throughput) of trying to keep redundant databases in different geographic areas in sync. Hence, you must deal with state explicitly.

You have to reduce the parts of your application that handle state to a minimum. Loss of a component means the loss of application state that it holds.

This is classic advice for scaling systems, but is more critical in the cloud. In the past we created stateless middle tier components for easier scalability, and relied on the data tier to handle scale. You then rely on clusters or technology built into the database (transaction logs, etc.). While stateless components are still an excellent idea, we cannot always rely on the database to scale, and the possibility of database failure is a large risk.

The business layer and the domain layer should be stateless, and to the greatest extent possible the clients should hold whatever state they can. Stateless services can be added or removed easily to handle changes in demand or the failure of a service instance, since you have decoupled functionality. Try to build services that are as atomic as possible because that makes it easier to scale or recover from failure by using redundancy. Here, atomic does not mean small.

Suppose you put customer information in the same service as your catalog service. If the customer information service goes down, so does the catalog. You should be able to check in people to your flight even if you cannot give the prices for tomorrow's flights.

There are other techniques you can use. For example, if the bill paying service is not available, you can usually use a transactional queue, and just retry the payment until the service is available. That is one of the reasons why banks, for example, say that they need 24 hours for an electronic payment that could be processed immediately. The odds that the payment service will be down for 24 hours are miniscule.

Also don't forget infrastructure pieces as to where logs are stored. You should probably back them up frequently.

So what about where state has to be stored, say in the data tier? This is a complicated problem which I have discussed this before in both a blog post and a presentation . It basically boils down to the question: what is the acceptable level of data loss? As it turns out, in many applications you do not have to be absolutely consistent in all places, and you can relax consistency constraints to get scalability and reliability. Now you may think this is ridiculous, data can never be lost. But think about how business is actually done.

Airline reservation systems separate out the flight query database, from the transactional database where flights are booked. As a result, occasionally a flight or a price you thought was available is not. But if they did not do that, the performance of making reservations would be very poor. More business would be lost under strict consistency than under relaxed consistency constraints. Why does Amazon use an email system for notifying you of your book order? To scale the user interface and to avoid performance problems due to abandoned shopping carts. You have to ask the question: What is the cost of an apology for the data loss?

What kind of availability are your customers actually willing to pay for, as opposed to what they say they want? Given a choice, do they really want absolute consistency in all cases? If you used replication over a short period of time to another data center, and a data center was destroyed by a hurricane, and a certain amount of data was lost, how terrible would that be?

Consider grouping your components in units of failure. If you have components of type α, β, and γ, you could put all α on a single host, all β on a separate host, or all γ on a separate host. Or you could put groups of α, β, γ on separate hosts. The latter would cause a complete failure on a loss assuming affinity to a given machine. The former would only result in a failure of α functionality.

What do you do if your components fail? Do you have to reroute traffic to another data store, or data center? Do you need to add more instances of a component? You have to monitor your components and understand why they fail. Under certain circumstances, you can degrade performance. Caching might help in keeping your application running under failure.

Degrade gracefully and predictably. Know what you can live without.

Designing for Failure has been around a lot longer than cloud computing. As we have discussed in several other blog posts, cloud computing, as opposed to hosting in the cloud, is about the ability to acquire or release computing resources as necessary. Acquiring more resources allows you to keep up with demand, or to compensate for a failed instance of a resource.

You must examine every source of dependency in your application: third party libraries, hardware, software interfaces between parts of your own application, TCPIP ports, DNS servers, message queues, database drivers, database size, latencies, to name just a few. These include third party services such as credit card processors, fraud detection services, and geocoding services.

You also have to examine your queries because small queries can become large overnight as you scale. This is why search providers limit the result set that they return. See what kind of joins your ORM is producing when it handles inheritance. Look at the number of objects coming back from a DCOM or RMI call.

Any one of these could fail, or cause latency. As we discussed in a previous post, any potential long latency has to be treated as a potential failure. You need to avoid single points of failure because they are potential bottlenecks or failure points.

Acquiring more resources costs more money. So every strategy is a tradeoff between keeping the application responding (available and scalable) and how much it costs. This is driven of course, by what customers are willingness to pay. Every strategy has to undergo a cost benefit analysis.

The more you approach 100% availability, however, the more the law of diminishing return sets in. I cannot here tell you which problems you should solve, and which you can safely ignore. It depends on your application and your customers. I can tell you that every component is a potential source of failure.

Avoid single points of failure. Accept the fact that you have to build a distributed system.

You have to make sure your cloud application is not brittle. Make your components more resistant to failure. Bridges can withstand more traffic than their largest anticipated load. Since you can add and remove resources in a cloud computing environment, your margin of safety can expand or contract as your load expands or contracts. Nonetheless, adding and removing resources is not instantaneous. You have to make sure that your system can handle a "normal load".

How do you determine your margin of safety?

Look at every resource you use in the system: database sizes, bandwidth, virtual memory, CPU, network latencies, and the response times of your software and your third party components. See how they respond under various types of commands, reports, and queries over time. Because of the economic costs, and possible performance hits with handling failure, you want to ensure your application in its normal state of operations can handle the load. You might want to factor in some likely scenarios, for instance, and make the resources required larger than might be ordinarily needed. Make sure all errors are handled, even unlikely ones. Return clear error codes that indicate what the problem is to the best of your ability. When problems occur, you might degrade performance rather than eliminate functionality. Determine what functionality is essential and what is not. During the Amazon outage last year Netflix turned off personalized movie lists, but you could still get lists of movies and play them.

Use a Margin of Safety when determining the resources needed for your application.

In the simple example we have been discussing, the consequences of a failure appear immediately to the user. In a more complicated architecture there are many more tiers and many more dependencies. With more dependencies, more problems can possibly result from poor decisions on how to handle failure. Those dependencies include other applications in your own shop, third party libraries that you don't control, the internet, etc. For example, if your order queues fail, you cannot do orders. If your customer service app fails, you cannot retrieve member information. Unhandled failures propagate (like cracks) throughout your application.

Failures Cascade - a unhandled failure in one part of your system becomes a failure of your application.

In deciding on how to respond to failure we have to distinguish between two types of failure: transient failures and resource failures. Transient failures are not due to component failure, but a resource temporarily under load that cannot respond as fast as you had assumed. With resource failures you have to have an alternative strategy because a component is not available.

Transient failures occur for short periods of time. The typical response is to retry the operation after a short period of time. But questions still remain. How often do you retry? What is a short period of time? What do you with the data during the retry? On the other hand, remember that just as failures cascade, so do delays. While you are waiting or retrying, scarce resources are being used (threads, memory, TCPIP ports, database connections) that cannot be used for other requests.

Go back to our WCF example and look at the try/catch block. If we had to do a retry how would we change the logic? We will have to adopt a whole different strategy to handle failure, a retry loop inside the catch handler would not be enough because other failures could reoccur, and not every error would allow a retry. You have to design the entire routine around expecting failure, because as we discussed in our last post, failures happen.

Since slow responses usually come from resource bottlenecks, you have to treat them as failures if you are going to have reasonable availability. Which means that transient failure can soon look like resource failures. So what do you do? Retry for a limited amount time and then give up. In addition, never block on an I/O, timeout and assume failure.

From the point of view of architecture and design, there is really no such thing as a transient failure. If you have a transient failure, fail fast and treat it as a resource failure.

Why is failure endemic to distributed systems?

In the past two blog posts we talked about a hypothetical ASP.NET application. Let's add a second tier to this app where we make a call to a web service. We will then have some version of the following code fragment which resembles something everybody has written:

ClientProxy client = new ClientProxy();
int result = client.Do(a, b, c);

What's wrong with this?

We have assumed that the call would succeed. Why would it not succeed? At the very minimum you could have a network timeout. You are assuming you have control over a resource that your really do not. The fundamental concept in designing for failure is to understand that any interface between two components can fail. So we rewrite the code as follows:

try
{
      ClientProxy client = new ClientProxy();
      int result = client.Do (a, b, c);
}
      catch (Exception ex)
{
      ????
}

But now what do you do in the exception handler?

In this simple example, how many times do you retry? When you give up do you cache the input, or do you make the user enter it over again? Suppose the service on the other side stopped working? What happens when the underlying hardware crashes, and your application has to be restarted. Where is the user data then?

What about total failure conditions? Do you "go to" out of the exception handler? Where do you go to?

You cannot program your way out of a failure condition in code that is based on the assumption that everything works properly. You have to architect and design for failure conditions from the start. The critical issue is how you respond to that failure.

Here is the fundamental principle of designing for failure:

Continuing out examination of hosting options from the last post, perhaps, the cheaper options have lower reliability. Here are the availability numbers for our providers:

If Amazon and Azure are more expensive with a similar SLA, why use them?

The rate for cloud computing infrastructure is more expensive because it allows you to pay only for what you use. Not only does this allow you to use computing resources more economically, it allows you to design around outages. With a cloud computing infrastructure, you can reach, if you wish to pay for it, very close to 100% availability.

This gets to the essence of the matter. You are doing cloud computing when you are interested in one of two things:

1. Paying for only the computing resources you use so you do not have to buy enough hardware for peak scenarios that happen infrequently.
2. You want to achieve very high reliability, with almost no downtime. You have to design for failure.

We often refer to these goals as scalability and availability. Scalability is making sure your application can handle increase load with reasonable performance. Availability is making sure your application has reasonable performance for a reasonable amount of time. What is reasonable, depends on the economics of your business environment.

Technically they are different problems. Depending on your system load, you could have reasonable availability for the vast majority of the times your customer wants, and just be very unresponsive under very heavy loads. Or, you could handle very large loads for small periods of time, and be very unresponsive the remainder of the time.

But for most applications they are closely related. To have high scalability requires you not only to be able to acquire more computing resources, but it requires you to be able to detect and handle failures of existing computing resources. High availability requires the same thing.

Designing for failure is cloud computing.

Lincoln said that calling a tail a leg does not make a horse a five legged animal. Hosting an application in a cloud computing environment does not mean that you are doing cloud computing.

One of the reasons that people are attracted to cloud computing is because they do not have to host their own infrastructure or run a data center. But that is true of traditional hosting. Now the feature sets of a cloud computing environment may make you want to host there, but that is only an enlightened hosting decision.

Let's make this clear with an example.
Suppose I decide that I do not want to run my traditional ASP.NET application in my data center. I have a web front end, and a back-end database.

Potentially, I have to pay for:

Let's assume this translates to the following configuration:

Researching some of the Service Providers I found the following costs for this configuration:

None of these providers are traditional hosters (provide your own machines, and rent bandwidth, cooling, or electricity). Nor are ORCS Web's and Rackspace's offerings to build a colocated data center considered.

Virtualizing your data center is not considered here as cloud computing because you still have to build out to maximum capacity. Nontheless, it might be considered cloud computing from the point of view of your internal users if they can get resources elastically.

So we see there are cheaper options if you just want to host. Now if you want to some feature that one hosting company has that the other does not, say blob storage, you could use that in conjunction with your host (say Amazon or Azure blobs).

Hosting is hosting no matter where you do it. Hosting an application in a cloud computing environment does not mean you are doing cloud computing.

I have run some simple performance tests on Azure table storage. Thinking about them reinforced in my mind what kinds of applications should run on Azure, and the relationships between Azure storage tables and SQL Azure.

I have found insert rates on the order of 30-200 milliseconds for a single insert into Azure table storage . It is also on the order of magnitude found in the more elaborate testing reported in Early Observations on the Performance of Windows Azure (Zach Hill, et. al.). This paper looks at the performance of Azure tables, blobs, and queues under various circumstances including the number of concurrent clients.

These rates not blazingly fast. On the other hand, these performance numbers are good for a huge percent of applications that are written. It also may mean that you do not want to do a large number of small inserts into table storage.

Thinking about these results reinforced in my mind that the point of table storage is not that it is super fast, but its performance is more consistent than a relational database where massive scalability can lead to performance degradations in the lock manager. I would assume you would see these kinds of numbers in all of the major cloud vendors such as Amazon and Google.

It also got me thinking about the types of applications that should run on Azure, or any cloud platform for that matter.

The big advantage of cloud computing comes from its elastic scale, and its opportunity to outsource parts of the application stack (virtualization, operating systems, networking, etc.). This comes from the economy of scale of commodity hardware. On the other hand, if you are sophisticated enough, and you have the money, you could buy more sophisticated hardware, and get greater performance.

If you need really high performance (say you are doing online transaction processing) cloud computing is not for you, and probably will not be for another 30 years.

A colleague sent an article about cloud computing to me. I found this interesting nugget inside. Apparently precipitation can be a problem inside of a computing cloud.

"This isn't the only problem faced by SHS. According to Hruboska, "We set up in Iceland because of the lower costs associated with cooling our servers in a northern climate [a huge savings and environment friendly] and because of the availability of cheap, geothermal energy. What we didn't expect is that by running our cloud in a cooler environment that the moisture within the cloud would condense, freeze due to the low temperatures, and effectively snowcrash our servers. Our physical maintenance bill is higher as a result but our overall expenses are still lower by hosting our servers here outside of Reykjavik." Other companies are operating server farms in Whitehorse, Helsinki, and Vladivostok for similar reasons and are running into similar condensation problems as SHS."

This was quoted from: Dr. Dobb's Agile Update 04/09

Windows Azure provides two storage mechanisms: SQL Azure and Azure Storage tables. Which one should you use?

Can Relational Databases Scale?

SQL Azure is basically SQL Server in the cloud. To get meaningful results from a query, you need a consistent set of data.

Transactions allow for data to be inserted according to the ACID principle: all related information is changed together. The longer the database lock manager keeps locks, the higher the likelihood two transactions will modify the same data. As transactions wait for locks to clear, transactions will either be slower to complete, or transactions will time out and must be abandoned or retried. Data availability decreases.

Content distribution networks enable read-only data to be delivered quickly to overcome the speed of light boundary. They are useless for modifiable data. The laws of physics drive a set of diminishing economic returns on bandwidth. You can only move so much data so fast.

Jim Gray pointed out years ago that computational power gets cheaper faster than network bandwidth. It makes more economic sense to compute where the data is rather than moving it to a computing center. Data is often naturally distributed. Is connectivity to that data always possible? Some people believe that connectivity will be always available. Cell phone connectivity problems, data center outages, equipment upgrades, and last mile problems indicate that is never going to happen.

Computing in multiple places leads to increased latency. Latency means longer lock retention. Increased locked retention means decreased availability.

Most people think of scaling in terms of large number of users: Amazon, Facebook, or Google. Latency also leads to scalability based on geographic distribution of users, transmission of a large quantity of data, or any bottleneck that lengthens the time of a database transaction.

The economics of distributed computing argue in favor of many small machines, rather than one large machine. Google does not handle its search system with one large machine, but many commodity processors. If you have one large database, scaling up to a new machine can cost hours or days.

The CAP Theorem

Eric Brewer’s CAP Theorem summarizes the discussion. Given the constraints of consistency, availability, and partitioning, you can only have two of the three. We are comfortable with the world of single database/database cluster with minimal latency where we have consistency and availability.

Partitioning Data

If we are forced to partition our data should we give up on availability or consistency? Let us first look at the best way to partition, and then ask whether we want consistency or availability. What is the best way to partition?

If economics, the laws of physics, and current technology limits argue in favor of partitioning, what is the best way to partition? Distributed objects, whether by DCOM, CORBA, or RMI failed for many reasons . The RPC model increases latencies that inhibit scalability. You cannot ignore the existence of the network. Distributed transactions fail as well because once you get beyond a local network the latencies with two-phase commit impede scalability. Two better alternatives exist: a key value/type store such as Azure Storage Services, or partitioning data across relational databases without distributed transactions.

Storage Services allow multiple partitions of tables with entries. Only CRUD operations exist: no foreign key relations, no joins, no constraints, and no schemas. Consistency must be handled programmatically. This model works well with tens of hundreds of commoity processors, and can achieve massive scalability. One can partition SQL Azure horizontally or vertically. With horizontal partitioning we divide table rows across the database. With vertical partitioning we divide table columns across databases. Within the databases you have transactional consistency, but there are no transactions across databases.

Horizontal partitioning works especially well when the data divides naturally: company subsidiaries that are geographically separate, historical analysis, or of different functional areas such as user feedback and active orders. Vertical partitioning works well when updates and queries use different pieces of data. In all these cases we have to deal with data that might be stale or inconsistent.

Consistency or Availability?

Ask a simple question: What is the cost of an apology? The number of available books in Amazon is a cached value, not guaranteed to be correct. If Amazon ran a distributed transaction over all your shopping cart orders, the book inventory system, and the shipping system, they could never build a massively scalable front end user interface. Transactions would be dependent on user interactions that could range from 5 seconds to hours, assuming the shopping cart is not abandoned. It is impractical to keep database locks that long. Since most of the time you get your book, availability is a better choice that consistency.

Airline reservation systems are similar. A database used for read-only flight shopping is updated periodically. Another database is for reservations. Occasionally, you cannot get the price or flight you wanted. Using one database to achieve consistency would make searching for fares. or making reservations take forever.

Both cases have an ultimate source of truth: the inventory database, or the reservations database. Businesses have to be prepared to apologize anyway. Checks bounce, the last book in the inventory turns out to be defective, or the vendor drops the last crystal vase. We often have to make records and reality consistent.

Software State is not the State of the World

We have fostered a myth that the state of the software has to be always identical to the state of the world. This often makes software applications difficult to use, or impossible to write. Deciding what the cost of getting it absolutely right is a business decision. As Amazon and the airlines illustrate, the cost of lost business and convenience sometimes offsets the occasional problems of inconsistent data. You must then design for eventual consistency.

Summary

Scalability is based on the constraints of your application, the volume of data transmitted, or the number and geographic distribution of your users.

Need absolute consistency? Use the relational model. Need high availability? Use Azure tables, or the partitioned relational model. Availability is a subjective measure. You might partition and still get consistency. If the nature of your world changes, however, it is not easy to shift from the relational model to a partitioned model.

Determining how to divide your Azure table storage into multiple partitions is based on how your data is accessed. Here is an example of how to partition data assuming that reads predominate over writes.

Consider an application that sells tickets to various events. Typical questions and the attributes accessed for the queries are:

The queries are listed in frequency order. The most common query is about how many tickets are available for an event.

The most common combination of attributes is artist or date for a given location. The most common query uses event, date, and location.

With Azure tables you only have two keys: partition and row. The fastest query is always the one based on the partition key.

This leads us to the suggestion that the partition key should be location since it is involved with all but one of the queries. The row key should be date concatenated with event. This gives a quick result for the most common query. The remaining queries require table scans. All but one are helped by the partitioning scheme. In reality, that query is probably location based as well.

The added bonus of this arrangement is that it allows for geographic distribution to data centers closest to the customers.

Popular consciousness creates popular myths. Here are some myths about cloud computing.

1. Total reliance on the cloud is foolish or scary.

So is total reliance on the Internet or the electric grid, or the transportation network to get us our food. In fact, I imagine someone in 4000 BCE said: dwelling in cities is dangerous, and we should not let people farm to support them. Come to think of it, people are still saying it.

Dependency is a fact of life. It has been a fact of human existence since the first division of labor. Nonetheless, we should have contingency plans. Any organization that hosts any application should understand what the impact of an outage would be. It might be the cloud application itself is down, or the Internet connectivity is slow. Your contingency plan does depend on the nature of your application. After all, hospitals still have emergency generators for surgery, and we store a couple of day’s food in the refrigerator.

On the other hand, maybe you did build your own house, or sew your own clothing. Perhaps a day without email or applications (i.e. the Sabbath) might be a good idea after all.

Dependency, by itself is not an argument against Cloud Computing. It is the consequences of that dependency that matter. For most applications, even some of those considered the most critical; we could actual do without for a few hours.

2. Security is better/worse in the cloud

Data in the cloud is insecure. Data in the cloud is more secure. Nothing is quite like security for generating fear and myths.

The first question you always have to ask is: secure compared to what? Fort Knox? Money in your mattress? After all, the most secure computer is disconnected from the Internet. If you are really paranoid you can turn it off. Of course, it is now difficult to get any work done.

Is data in the cloud more or less secure? Is it secure compared to a corporate data center? There certainly have been some well publicized incidents of corporate data breaches. There are probably even more cases that have not been reported. Have there been any incidents in a cloud computing center? None yet, but there will be. If there are, they might be the fault of the application designers or owners. The same people who create insecure applications in their own data centers can certainly create them in the cloud. Cloud computing centers might be able to better focus on security (physical, data, and application) because that is part of their expertise.

On the other hand, with all that computation and storage focused in one place, people fear that cloud computing data centers may be an inviting target for attack. Employees of cloud computing centers may snoop. So can employees of a corporate data center. Will industrial espionage be easier in a cloud computing center? I am just waiting for the movie. Perhaps you are safer with people who specialize in keeping data centers secure, than a lot of smaller data centers. Bank robberies are not as frequent as they used to be.

Cloud computing centers may lack compliance certification, and that is a problem. On the other hand, as Berkeley researchers have argued, cloud computing may make Denial of Service attacks economically unfeasible.

It is also currently unknown if security breaches in one virtual machine can cause a compromise of the underlying physical hardware.

As with any hosted application, the builders of the application share responsibility with the cloud providers. You might want to investigate how well capitalized, and what the security plans of your provider are.

The best security is to park your bicycle next to a better bicycle with a worse lock.

3. Cloud is reliable / unreliable

My electric utility only gets 99.98% uptime. So much for the vaunted four nines. How much uptime does Facebook really need? You need to understand exactly what your application requirements are, and the consequences of failure.

I do not know of a single cloud computing vendor that offers a service level agreement with real remediation in case of an outage. Don’t forget that as with any hosted application you are still subject to the vagaries of the external network connections. The data center may be fine, but when Michael Jackson died, the response time of the Internet slowed to a crawl: nothing like a self-inflicted denial of service attack.

Given the current fetish over net neutrality, the packets carrying the output of your pacemaker to your cardiologist get the same priority as someone streaming Lady Gaga’s latest hit.

First define the reliability requirements that your application needs, then decide the appropriate course of action.

4. Cloud computing requires no social infrastructure

Suppose your cloud computer provider goes bankrupt, and the machines are seized as collateral for the debt. What happens to your applications and data? We may need an FDIC-like organization to handle cloud computing provider insolvencies. Some regulation would need to be in place to handle continuity of service during takeovers.

The economies of scale may lead us down the same road that the electrical utilities and the water companies went. The small scale providers were eventually taken over by the larger providers and the resulting monopolies were regulated.

Companies, such as financial services, that operate in heavily regulated industries will be reluctant to use cloud computing providers unless there is some clarity to their legal responsibility for data in the cloud. On the other hand, Microsoft is selling its cloud computing fabric so that third parties might set up private clouds for various industries. Whether they are true computing clouds or just hosting services with flexible virtualization would depend on the actual scaling potential of the data center.

"Government, without popular information, or the means of acquiring it, is but a Prologue to a Farce or a Tragedy; or, perhaps both. Knowledge will forever govern ignorance."    James Madison

Control over information is a societal danger similar to control over economic resources or political power. Representative government will not survive without the information to help us create meaningful policies. Otherwise, advocates will too easily lead us to the conclusion they want us to support.

How does one get access to this data?

Right now, it is not easy to get access to authoritative data. If you have money you search for it, purchase it, or do the research to obtain it. Often, you have to negotiate licensing and payment terms. Why can’t we shop for data the same way we find food, clothing, shelter, or leisure activities? None of these activities requires extensive searches or complex legal negotiations.

Why can’t we have a marketplace for data?

Microsoft Dallas is a marketplace for data. It provides a standard way to purchase, license, and download data. Currently it is a CTP, and no doubt will undergo a name change, but the idea will not.

The data providers could be commercial or private. Right now, they range from government agencies such as NASA or the UN to private concerns such as Info USA and NAVTEQ. You can easily find out their reputations so you know how authoritative they are.

As a CTP there is no charge, but the product offering will have either transaction/query or subscription based pricing. Microsoft has promised “easy to understand licensing”.

There is one billing relationship in the marketplace because Microsoft will handle the payment mechanisms. Content Providers will not have to bill individual users. They will not have to write a licensing agreement for each user. Large provider organizations can deal with businesses or individuals that in other circumstances would not have provided a reasonable economic return. Small data providers can offer their data where it would have previously been economically unfeasible. Content Users would then be able to easily find data that would have been difficult to find or otherwise unavailable. The licensing terms will be very clear, avoiding another potential legal headache. Small businesses can create new business opportunities.

The marketplace itself is scalable because it runs on Microsoft Azure.

For application developers, Dallas is about your imagination. What kind of business combinations can you imagine?

Dallas will use the standard OData API. Hence Dallas data can be used from Java, PHP, or on an IPhone. The data itself can be structured or unstructured.

An example of unstructured data is the Mars rover pictures. The Associated Press uses both structured and unstructured data. The news articles are just text, but there are relationships between various story categories.

Dallas can integrate with the Azure AppFabric Access Control Service.

The standard API is very simple. The only real limit is your imagining the possibilities for combining data together.

What kind of combinations can you think of?