Skip navigation

Category Archives: Uncategorized

This is my first Cloudonomics.com post in a while, as I’ve been engaged in developing a number of Monte Carlo simulations and detailed proofs of The 10 Laws of Cloudonomics.  Here’s an overview of the results, with summaries of conclusions for those that don’t want to read through over 200 pages of proofs and analyses spanning economics, behavioral economics, calculus, probability, statistics, trigonometry, system dynamics, and computational complexity theory.  Links to the papers and supporting simulations at ComplexModels.com are included.

Here are the 10 Laws and a few bonus insights:

The First Law of Cloudonomics: “Utility services cost less even though they cost more”

In other words, “More is Less.” Cloud computing can be viewed as a means of reducing cost, increasing revenue, improving business agility, and enhancing the total customer experience. Let’s focus on cost for a minute. There are some who believe that the unit cost of Cloud Computing is lower than that of “well run” enterprise data centers, some who believe the opposite, and inconsistent data supporting both viewpoints. Technology convergence in hardware, e.g., through increasing diffusion of containerized data centers, and in software, e.g., via off-the-shelf integrated management tools, would appear to be shifting cost differentials, anyway. The correct way to look at the problem, however, is not unit cost, but total cost. Here’s where utility pricing, i.e., pay-per-use, makes a critical difference. As I show in the analysis “Mathematical Proof of the Inevitability of Cloud Computing” (PDF) and supporting “Value of Utility in the Cloud” (simulation), all other things being equal:

1) If cloud services have a lower unit cost than a do-it-yourself dedicated solution does, you should use them; after all, why not save money?

2) If the unit cost of cloud services is higher than do-it-yourself, but demand is spiky enough, even a pure cloud solution will have a lower total cost than a do-it-yourself solution.  The trick is that the pay-per-use model of the cloud means that the unit cost may be higher when the services are used, but it is zero when not used, unlike owned, dedicated resources.

3) In most cases, it’s economically optimal to utilize a hybrid model: dedicated resources that can be highly utilized, complemented by pay-per-use resources to handle the spikes. This is similar to owning a car for daily use but renting one occasionally. It is cheaper than either always renting, or, owning a car everywhere you might need one. The fraction of time spent near the peak demand turns out to be the key factor in determining the appropriate balance.

The phrase “all other things being equal” is a key one, because valid differences between approaches, behavioral economics factors, or network costs can shift the breakeven points and thus tip the balance.

The Second Law of Cloudonomics: “On-demand trumps forecasting”

I quantify this in “Time is Money: The Value of On-Demand” (PDF) by defining an asymmetric penalty function associated with excess resources and with unserved demand, and examining how various factors influence the penalty costs.

It is important to distinguish between the terms “on-demand” and “pay-per-use.”  Although they are often related, they drive different benefits and are logically separable: a hotel room reserved a month in advance may be pay-per-use but is not on-demand.

If demand is linearly increasing, even manual provisioning of dedicated resources can be effective. If demand is variable, but can be effectively forecasted and resources are sufficiently flexible, on-demand resourcing is of limited net value.

In most cases, though, when demand varies or is unpredictable, the benefit of on-demand can be sub-linear, linear, or exponential, depending on the demand curve:

1) If demand growth is exponential, the gap associated with any fixed delay is also exponential.  Colloquially, if you are responding to needs within a standard fixed interval, you will fall further behind at an accelerating rate.

2) If growth is linear, the penalty is proportional to the provisioning delay.  Consequently, halving the provisioning interval will halve the penalty.

3) Some demand processes can to some extent be characterized as random walks.  After a time t, the distance that they’ve “wandered” is proportional to √t, as demonstrated via this Random Walk (simulation)  Consequently, it takes a four-fold reduction in time to halve the penalty cost.

The “Value of Utility in the Cloud” (simulation) enables assessment of different provisioning intervals and their resulting costs in light of the demand function.

The Third Law of Cloudonomics: “The peak of the sum is never greater than the sum of the peaks”

and

The Fourth Law of Cloudonomics: “Aggregate demand is smoother than individual”

These two laws are related, and I address them in depth in “Smooth Operator: The Value of Demand Aggregation” (PDF) as well as in simulations.  Adding together independent demands leads to a smoothing effect, as peaks and valleys have a tendency to cancel each other out.  This leads to beneficial economics due to what I’ve called the “statistics of scale.”  As an example, suppose we can assume that each individual demand is normally distributed with identical mean and variance.  Then, the coefficient of variation of n demands is only 1/√n as great as an individual demand.  In the limit, a service provider with an infinite number of customers can theoretically achieve 100% utilization, leading to compelling economic advantages versus a “do-it-yourself” approach.  In the real world, the 1/√n effect means that being larger is better, but even mid-sized service providers can generate meaningful and real economic value.

While it is always beneficial for a customer with relatively spiky demand to use a service provider to average things out with one with relatively flat demand, the reverse is not necessarily true.  The implication is that customers with similar degrees of variability (i.e., standard deviations and coefficients of variation) are likely to band together (i.e., reach a “separating equilibrium”) either via different service providers or via different tranches of pricing with incentive compatibility and self-selection assured by permitted scalability SLAs.

The Value of Resource Pooling (simulation) illustrates this effect: as the number of sites increases, the total capacity required for the pool decreases relative to the sum of partitioned capacities. Even more simply, the Value of Aggregation (simulation) illustrates the statistical effect: the normalized dispersion of the sum closes in on the mean as the number of customers is increased.

The Fifth Law of Cloudonomics: “Average unit costs are reduced by distributing fixed costs over more units of output”

This law points out that economies of scale can apply to cloud providers just as well as it does, say, paper mills or power plants.  However, the concept of “economies of scale” tends to be primarily applied to production costs without consideration of demand patterns. For example, a large paper mill may produce a sheet of paper more cheaply than small batch production can, regardless of how much, how often, or when people choose to write or print. For services such as those in the cloud, however, it is useful to separate out factors such as volume discounts or distribution of costs to develop automation software across a broader base from the demand-side statistics of scale benefits addressed above.

The Sixth Law of Cloudonomics: “Superiority in numbers is the most important factor in the result of a combat (Clausewitz)”

Regardless of whether there are any economies or diseconomies of scale, the degree of scale can be important in a variety of areas. One example is global coverage. Another example is in cyberattacks such as Distributed Denial of Service attacks, where large numbers of attacking bots can overwhelm limited web server resources.  As some botnets are millions strong, it suggests that a large cloud (including large network-based defenses) can be required to survive such an attack.

The Seventh Law of Cloudonomics: “Space-time is a continuum (Einstein/Minkowski)”

and

The Eighth Law of Cloudonomics: “Dispersion is the inverse square of latency”

For parallelizable tasks, the number of resources can be traded off against time.  Large search providers, for example, may use a thousand processors in parallel to respond to search queries in sub-second times.  However, in today’s distributed environments, including the Internet, latency due to transmission delays over a network, e.g., due to physical signal propagation, must also be considered.  If we want to reduce that latency, there are diminishing returns to increased investment, since it takes four times as many nodes to reduce latency by half on a plane.  On the surface of the earth (or any sphere), the mechanics of covering circular areas defining worst-case or expected latency match this rule more and more closely as the size of the area covered decreases, but even at the scale of continents the Eighth Law is within a few percentage points of being accurate.

In “As Time Goes By: The Law of Cloud Response Time (PDF),” I explore both laws in depth, and propose that Amdahl’s Law should be superseded by a Law of Cloud Response Time, where response time T follows T = F + N/√n + P/p, where F is a fixed time, N is the network latency in the case of one service node, n is the number of service nodes, P is the time to run a parallelizable portion of code on one processor, and p is the number of processors.  If one has Q processors to deploy, the lowest time T then occurs when the number of nodes n equals (QN/2P)^2/3.

While the exact value is thus dependent on the ratio between N and P, as the quantity of resources grows, the relative contribution of dispersion declines.  Another key insight, which I prove in the paper, is that the cost structure of elasticity and the cost structure of dispersion in the cloud imply that in many cases, response time can be dramatically reduced without a cost penalty.

The Value of Dispersion in Latency Reduction (simulation) shows this √n effect on a plane, both for service nodes deployed in regular lattices as well as randomly positioned.

The Ninth Law of Cloudonomics: “Don’t put all your eggs in one basket”

The reliability of a system with n redundant components, each with reliability r, is 1-[(1-r)^n]. The good news is that higher reliability can be achieved through a judicious mix of replicated components, monitoring, management, and recovery processes, and overall architecture.  The bad news is that no finite amount of replication will achieve perfect reliability.

The Tenth Law of Cloudonomics: “An object at rest tends to stay at rest (Newton)”

A preferred option may be infeasible due to switching or migration costs as well as psychological or behavioral economic factors.  For example, power costs may be lower at a new site, but the costs of early contract or lease termination, temporary operations replication, testing, and physical equipment moves may make it challenging to migrate.  Clouds may offer advantaged economics, but the cost and time to rewrite thousands or millions of lines of code alter those economics, suggesting that traditional / legacy environments will need to coexist with clouds for a long time.  In addition, there are numerous behavioral economics factors that support use of the cloud—for example, hyperbolic discounting—or conversely, support traditional operations—for example, a need for control.

Pay-per-use is a Dominant Strategy

In “The Market for Melons: Quantity Uncertainty and the Market Mechanism” (PDF) I prove the dominance of pay-per-use pricing over flat-rate pricing in competitive environments meeting certain basic conditions, such as non-trivial price dispersion and rational, active, maximizing consumers.  This simulation demonstrates the effect. As the simulation runs, light users defect to pay-per-use plans, heavy ones to flat-rate ones. The flat-rate price rises, and defections tilt increasingly to pay-per-use. In the terminal state, virtually all customers are on pay-per-use plans. Perhaps surprisingly, even as consumers switch plans to reduce their costs, the total spend in such environments doesn’t change, in other words, aggregate shifts in plan selection are revenue neutral.  This theoretical result matches the experience of major providers.

Cloud Computing is Computationally Intractable

In “Cloud Computing is NP-Complete” (PDF), I prove that a basic problem in Cloud Computing, that of matching resources to demand over a network, is computationally intractable, even if there are sufficient total resources in the system to meet the aggregate demand.  This result is something like the Heisenberg Uncertainty Principle, where position and momentum cannot simultaneously be precisely known, or Godel’s Proof that any non-trivial axiomatic system will either be incomplete or inconsistent.  It implies that a “perfect solution” that optimizes cost may not be computable in short enough time–thus there either must be excess resources in the system, to ensure that all demand can be satisfied; excess latency, as imperfect solutions utilize unnecessarily distant resources to fulfill demand; and/or excess overhead, to divide up demand to be served via multiple nodes.

Cloud Computing can represent different things to different stakeholders: a technology, a business model, or a development and operations strategy.  In addition, it may be viewed abstractly as distributed resources over a network with on-demand, pay-per-use attributes.  As such, certain laws and behaviors apply as we outline above.

Advertisements

Today GigaOm posted my latest thoughts on compelling cases for clouds. Here is a more in-depth compilation of viable business models for the cloud. I broadly define CLOUD as an acronym that encompasses not only cloud computing, but any Common, Location-independent, Online, Utility, on-Demand service, including hotel chains, electric utilities, mortgage lending, and rental car services, so I use some analogies from outside the “Cloud Computing” domain. In any event, the business models / use cases that I list here apply to most definitions of cloud computing and cloud services, and can also be viewed as being relevant to many on-line services or the web. In fact, if my analysis is correct, any web site or cloud service that has a valid business model should fall into one or more of the following buckets.

– Connections
– Communications
– Conversations
– Casting
rightarrow Connections are a natural function for the cloud. Until 1878, phone connections were done on a point-to-point basis. Starting in January of that year, the first cloud bridging function, aka telephone exchange, was deployed in New Haven. As a result, instead of needing multiple phones at your residence—one physical phone for every other party you might want to call—you just needed one phone to connect up to the cloud. Communications take place over connections, and conversations are the long running transactions of communications. Also, communications need not be unicast, but can be multicast, anycast, or broadcast. The key reason such functions need to be processed in the cloud is that n connections to a hub are less costly than n squared point-to-point connections.

 

Examples: telephony, microblogs

– Correspondences rightarrow Another type of connection is matching, or correspondence. For example, dating sites make connections between people, and search sites make connections between advertisers and people searching for information. To best determine a correspondence requires the greatest number of options for each user, inherently driving a cloud-based solution.

 

Examples: search and dating sites

– Collaboration
– Competition
– Co-opetition
– Commerce
rightarrow Collaboration occurs when multiple parties communicate, or interact, for the sake of achieving a common goal where all can simultaneously achieve the goal. Competition occurs when they interact for a common goal, but only one or a subset can achieve that goal. Commerce is a mix of collaboration and competition. People gather to brainstorm. They gather to compete in arenas or engage in commerce. They gather in real-world markets such as the New York Stock Exchange or a neighborhood flea market. Similarly, collaboration, competition, commerce, or other interactions are best done in a common location—real or virtual—because collaborators benefit from more collaborators, it’s not a competition without other competitors, buyers benefit from more sellers, and sellers benefit from more buyers.

 

Examples: on-line gaming, vertical market sites, on-line auctions.

– Clearing rightarrow When two parties engage in commerce, clearing, payments, and settlements can best be conducted in the cloud, by a neutral and trusted 3rd party. This is why lawyers have escrow accounts, and banks and brokerages utilize 3rd party financial intermediaries.

 

Examples: on-line payments and electronic funds clearinghouses

– Conversion rightarrow Whether natural language translation, file format conversion, currency conversion, media gateways, transcoding, transrating, or the like, conversion functions are often (but not always) best done in the cloud. This is especially true when there may be a multitude of parties interacting in many formats. Exceptions would be compression and encryption, which are best done on the originating end, and of course decompression and decryption, which are best done at the destination.

 

Examples: audio and video bridging, currency services

– Community rightarrow Communities are the pinnacle of the spectrum from connections to collaboration. Communities are built on connections where there are also shared goals, values, or interests. Since communities are made up of many participants, it doesn’t make sense for the community to reside with a single participant.

 

Examples: social networking sites

– Crowdsourcing rightarrow Crowdsourcing for prediction markets, recommendation engines, or tagging tends to be a cloud function. Although crowdsourcing or open innovation for a particular initiative might occur at a single participant’s site, maintaining a regular community of crowdsourcing participants belongs to the cloud.

 

Examples: on-line movie rental / streaming sites, news or tagging sites with popularity voting or recommendation engines.

– Commons
– Collections
rightarrow Anytime that access to resources is partial or intermittent, a commons generates economic value. For example, it is difficult to single-handedly use all of Central Park for all eternity. Space-division and time-division multiplexing of common (shared) resources is less costly than dedicated resources. A collection, e.g., the Library of Congress, is an information resource. This cloud model dates back thousands of years. Even when the same information object can be used simultaneously, such as an online books or patents database, economics still favor sharing, because the cost to assemble the collection is incurred once and/or is roughly proportional to the size of the collection, whereas the value or revenue is derived in accordance with the number of users and uses.

 

Examples: online book or patent databases

– Continuous Cross-Device Access
– Continuous Cross-Network Access
rightarrow Information on an untethered device may not be available to even the owner of that device, unless he or she is co-located. Putting the info in the cloud means it can be accessed from anywhere and any device, given the right user access control.

 

Examples: web mail or photos accessible from your laptop or your smartphone, or anyone else’s, if you choose.

– Cost rightarrow The cloud may be cheaper than do-it-yourself, depending on your costs and the cloud service provider’s prices. Cost may be lower due to economies of scale—the cloud provider has lower HW costs, SW costs, tooling, cooling, power, etc., which are low enough to offset some additional expenses, such as SG&A. Or the provider may have better statistics of scale—by multiplexing demand from multiple sources can achieve better utilization. Or, the provider may have end-to-end architecture benefits—for web sites, it may cost less to be hosted by an integrated service provider because all that traffic does not then need to further be transported to an enterprise data center.

 

Examples: electricity, cheaper to buy from the grid than run a nuclear power plant in your back yard

– CapEx
– Cash Flow
rightarrow Capital expenditures aren’t bad, unless they are for fixed capacity which is underutilized or insufficient, which is almost always the case. The other issue for smaller companies is that large capital expenditures may mean that there is not enough cash left to run the business.
Complementary Capacity for:
– Cloudbursting
– Continuity
– Center Migration
rightarrow I’ve explored the cloudonomics of hybrid clouds both at ComplexModels.com and in some articles. Briefly, lowest total cost can be achieved through judicious investment in dedicated resources and on-demand use of pay-per-use resources, subject to additional concerns such as cost to store and transport data. These can be used for cloudbursting, where the dedicated resources are temporarily insufficient to handle a demand spike and the cloud is used for the overflow. They can also be used for business continuity, in terms of both failover and data availability via mirroring or replication, when the dedicated resources are impaired, unavailable, or destroyed, and the cloud becomes the home for applications, services, or data. Or, the cloud can be used for data center migration, where applications can be housed temporarily.
– Comparative Advantage
– Context vs. Core
rightarrow David Ricardo showed that even when one entity enjoys cost advantages over another, it still makes sense to trade. Implications for IT shops: even if you can do everything yourself, it’s better to let someone else focus on context (non-core) activities, so you can devote your finite resources to things that develop or enhance competitive advantage.

 

Examples: outsourcing HR, CRM, tax prep, or stock picking via a mutual fund.

– Capabilities and Competencies rightarrow Sometimes, you can’t do it all yourself, so that’s not an option. Cloud providers, especially as the SaaS market continues to evolve, develop unique expertise based on learning curve effects, “economies of skill,” and specialization.

 

Examples: proprietary search algorithms and heuristics

– Celerity rightarrow “Celerity” is synonymous with “speed.” Cloud services can accelerate software development, testing, and deployment, by ready access to platforms and pre-deployed resources. Of course, using existing software in the cloud by definition is faster than trying to develop that same software from scratch.

 

Examples: software, platform, or infrastructure as a service

– Customer Experience
– Convenience
rightarrow Customers demand optimal experiences, or will go elsewhere. In today’s highly interactive world with globally distributed users, customer experience is enhanced through a geographically dispersed architecture. This is true on the web, with CDNs, but in the real world as well. It’s why there’s a coffee shop on every corner, rather than forcing you to fly all the way to a single consolidated location just to grab a cup of coffee.

 

Examples: content and application delivery networks.

– Consistency
– Currency
– Change Control
– Coordination
rightarrow The cloud is great at providing a single reference copy or golden master, whether it is the official time, the length of a meter, or the most up to date version of the presentation you and your colleagues have been working on. A single update applied to this master defines the current version.

 

Examples: time.gov or any SaaS service.

– Checkpoints rightarrow Checkpoints for controlling and validating transactions or entities entering a system from outside the system are optimally deployed at the perimeter of the system, because perimeters are smaller than areas, and surfaces are smaller than volumes. This is why customs, immigration, and border patrol are performed at points of entry.

 

Examples: network-based firewalls, anti-DDoS, email filtering for anti-virus or anti-spam.

– Chokepoints rightarrow Even if all transactions are valid, chokepoints for traffic management help manage the volume of inflow into a system to prevent the system from internally becoming too congested.

 

Examples: network traffic management, in digital networks, air traffic networks (gate delays), or highways.

– Choicepoints rightarrow Providing a multitude of contextually relevant choices is a natural cloud function, partly because these choices form a collection, and partly because the choicepoint acts as a point of entry.

 

Examples: on-line portals, including search results pages

– Combinations rightarrow Any or all of the above can be used together.

My first law of Cloudonomics is that “utilities cost less even though they cost more.”  This is a counter-intuitive observation: how can something cost less even though it costs more?  What I mean by this is that typically utility services must charge a “utility premium” for resources, over and above the cost of that resource.  Consider a enterprise that expends capital to acquire a $3,600 server, and uses it for 36 months, assuming zero residual value.  With straight line depreciation, this works out to $100 dollars a month.  If a utility service provider acquires that same server and rents it back to the enterprise, it can’t only charge $100.  That is only one element of the utility provider’s cost of doing business.  In fact, the provider must add sales, general and administrative costs, operating expenses for server management, and margin to provide an acceptable return to shareholders or lenders.  Consequently, the service provider must charge something like $140 or more.  But in addition to that, unless all the equipment provisioning is done under a stockless distribution model with long term leases, an additional factor comes into play: average utilization.  If average utilization of the service provider’s infrastructure is only, say, 50%, the provider might need to charge $280 for each server that is revenue-generating, because at the same time, it is generating $0 for each server that is idle.  Consequently, the utility premium, that is, the price differential relative to a non-utility price, has two components: that related to the service provider needing to add costs and margin on top of the base cost, and that related to utilization of the environment.  In this case, the utility premium might be 40% to 180%.

Of course, in the real world, additional factors come into play in an apples to apples comparison.  A large service provider may get deeper equipment discounts than a small or medium enterprise.  Tooling costs can be distributed over a larger base.  Staffing costs can be proportional to size of the environment, rather than requiring a minimum: for a small business with one server to have 24/7 monitoring requires five people on payroll — four people working 40 hour weeks doesn’t provide coverage for all 168 hours in the week, nor does it allow for vacations and sick days.  Due to factors such as these, utility service providers can generate some economic value to ameliorate the premium.

Why would any enterprise, instead of spending $100 a month, intentionally choose to spend $140 or $180 or $220 or $280 or more?

The answer is that the flip side of utility services is that they cost less or nothing when not in use.  While a hotel room may cost more per square foot per night when it is rented, it costs zero when it is not rented.  A rental car costs more per car class per day than financing, leasing, or depreciating the car, but costs zero when it is not rented.  A utility with a fully variable price, ends up costing less even though it costs more, as long as there is enough usage variability, i.e., demand variability to make the periods where nothing is being paid make up for the periods when the premium is being paid.  The specific metric in question is the peak-to-average ratio.  If this ratio is greater than the utility premium (expressed as a fraction), then the utility will cost less than the fixed environment.

My paper “The Evolution of Networked Computing Utilities” addresses this in more detail. and you can run a Monte Carlo simulation “The Value of Utility Resources in the Cloud” using your own assumptions about variable demand, utility premiums, and other costs associated with fixed and utility environments.  There are some other key assumptions that bear mentioning: the objective of the environment must be to serve demand, and demand must not be deferrable.

If a large spike in demand can just be ignored, then there is no need to ensure resource availability to serve it.  In real-world situations, there is an opportunity cost to unserved demand, e.g., revenue loss from customers that are turned away rather than being serviced.  The utility premium must be less than this opportunity cost, otherwise it is cheaper to do without the customer than to invest to capture their spend.  If demand is deferrable, then a fixed environment that is sized to the average demand is cheaper than a variable environment incurring the utility premium.  An example of non-deferrable demand is an emergency room: if you’ve just been hit by a truck, you’d prefer not to wait until next month to see the ER doctor.  An example of deferrable demand is having your house painted: if the painter is busy the next few weeks, no problem, you can wait.

The economics of serving non-deferrable demand then, somewhat counter-intuitively, demonstrate that more is less.

I’ve been thinking about characterizing the strategic advantages of cloud service providers — there must be a compelling value proposition vs. do-it-yourself, and not just for start-ups or small businesses, but for large enterprises as well.  I will post specific analyses of each law here, but an overview of the 10 Laws of Cloudonomics can be found at BusinessWeek, or as originally posted on the GigaOM Network.

  1. Utility services cost less even though they cost more.
  2. On-demand trumps forecasting.
  3. The peak of the sum is never greater than the sum of the peaks.
  4. Aggregate demand is smoother than individual.
  5. Average unit costs are reduced by distributing fixed costs over more units of output.
  6. Superiority in numbers is the most important factor in the result of a combat (Clausewitz).
  7. Space-time is a continuum (Einstein/Minkowski).
  8. Dispersion is the inverse square of latency.
  9. Don’t put all your eggs in one basket.
  10. An object at rest tends to stay at rest (Newton).

This blog is dedicated to quantitative analysis of the means by which cloud computing creates value. As an example, how do different strategies for node (data center) dispersion reduce end-to-end latency? I am Joe Weinman, and my simulation website is Complex Models.  My other blog, The Network Effect, is focused on network structure and dynamics.  I propose the “10 Laws of Cloudonomics” in BusinessWeek, courtesy of the GigaOM Network.