Tag Archives: PaaS

The Cloud is Dead! Long Live the Cloud!

The last few months have presented several large “black eyes” for cloud computing. In March, access to Google Apps (including Gmail) was interrupted for over 136,000 users. Last month, 13% of Amazon EC2 and RDS customers in the US Eastern Region had a complete service outage, affecting a range of well-known companies.

As a result, the cloud computing pundits have brought out the knives, attracting a lot of questions regarding the readiness of enterprise cloud computing. The gist of all of these arguments is that cloud computing is not something for mission-critical enterprise applications.

Many cloud computing advocates have countered these attacks by citing reliability statistics. For example, Google’s outage affected 0.02% of users for five days. This equates to 99.9997% up-time on an annualized basis—a statistic far better than that achieved by nearly all enterprises.

The Cloud: Dead or Alive?

Sunrise or sunset?
Sunrise or sunset?

So who is right? Is cloud computing “dead” for important use? Or is cloud computing better than anything enterprise management teams can provide?

They are both right… and both wrong.

How can this be true? A simple reason: enterprise (or business) computing is not simply provision of processing cycles or storage; it is a provision of a full range of computing services: systems engineering, processing, storage, customer service, technical support, backup and recovery, etc. It not simply a commodity transaction, but instead an ongoing business relationship managed by a human being and bound by service level agreements.

Those that view cloud computing solely as remote provision of computing resources are missing “The Big Picture.” Cloud computing is a service model for delivery of computing infrastructure, platforms and/or software. Those who wish to be successful providers of cloud computing for business need provide everything an internal enterprise computing provider would provide: computing resources and managed computing services—at higher quality and lower price.

The Cloud is Dead

This is why “The Cloud is Dead!” Companies who only provide remote processing cycles and storage are not providing enough for mission critical business use. They are simply providing the asset side of the equation—minus the controls critical for enterprise survival. Many of these providers—especially after the last two months—will soon be “dead” to enterprise buyers.

The Cloud is Alive

However, this is the very reason I say, “Long Live the Cloud!” The recent cloud computing problems highlight the huge market demand to add systems engineering, customer service, technical support, backup, recovery, and other human-oriented services to the cloud. (Imagine the benefits that businesses can gain by being able to “rent” the entire range of services and infrastructure their Internal Computing departments currently provides—but working from a more efficient, higher reliability infrastructure.) Cloud providers who meet the combined demand for lower-cost/higher-reliability computing AND managed services will make cloud computing a reality for big, mainstream enterprises—and do so very successfully.

The New, Complete Cloud

The nice thing—for business enterprises and cloud providers—is that there are so many ways to do this. Cloud computing providers can augment themselves with professional services teams, becoming “all in one” providers. Or they can remain focused on what they do best and partner with IT service providers who already have staff on hand and established procurement relationships with enterprises. Just imagine the ecosystems of cloud provision we will see arise over the next few years, competing with each other to provider better technology and service at a better price.

The Old Cloud is Dead! Long Live the New Cloud!

SaaS’ next pricing challenge, balancing easy budgeting with flexibilty: Four models

Balancing-Act-280px-tallAfter many years on the marketplace, the benefits of SaaS – especially when compared to owning everything yourself – are obvious and well known: Flexibility to “dial” capacity up or down as needed, pay-as-you-go pricing, access to high economies of scale with low investment… However, SaaS pricing modes often lacks two things that we all had when we “owned” all of our own resources (people, servers, on-premise licenses, etc.): predictability and control.

Back then it was easy to figure out what our budgets would be for the next year. Our starting budgets were based on existing payroll (for IT and software staff) and capital resources. We could easily decide (usually once per year) if we wanted to increase or decrease this by X%. Once we did this, it limited how much we could possible spend. The big challenge was prioritizing this budget across what turned out to always be too many projects. (Usually, the time required to build and ramp up systems kept this in check.)

Now things are different. Because we can buy SaaS-based services quickly and easy we can do more in less time and with far less work. However, this can lead to traps where we become “victims of our own success.” The SaaS-based online program we launch could get so much traffic that our costs quickly beyond grow beyond our budget. The easy access to storage could lead our teams to store too much, burning through money.

This problem is bad enough with commodity items (usually serviced with IaaS, Infrastructure-as-a-Service and PaaS, Platforms-as-a-Service). It can become “unmanageable” with complex portfolios of activity that do not easy fall into easy-to-size units (marketing and advertising campaigns, clinical trials, public sector programs, etc.) In these cases, SaaS creates a predictability problem for “both sides of the table”: customers cannot easily predict and control what their budgets will be while vendors cannot easily predict revenue recognition (affecting their ability to control business expansion).

SaaS vendors need to find viable solutions to this conundrum balancing SaaS’ flexibility with the basic need to budget and control costs. Here are four options:

The Fixed Price Model

Under this model, the price of the SaaS product is fixed, regardless of usage volume. A first blush, this can easy to budget (great for customers). However, it can kill TCO for vendors (the first time a customer wildly exceeds planned volume). Guarding against this leaves vendors two choices: raise prices (to guard against – leading to reduced demand) or KYFC “keeping your fingers crossed” (potentially risky).

This model is good in places where variability is low (e.g., sales force automation – one sales person can only generate so many contacts in a given month).

The On Retainer Model

This model draws from the ‘Old World’ of having lawyers and accountants – people who can perform a wide range of services – on retainer. It is somewhat tailored on a case-by-case basis, looking at expected volume across a wide portfolio of work and flattening this out into constant quarterly or monthly payments, adjusted by periodic reconciliation (based on actual vs. planned usage). This balances customer and vendor risk – and predictability with flexibility. However, it is complicated.

This model is good in places where usage is subject to “external factors” (e.g., portfolio-based business models like architecture, legal, research, campaign management, etc.)

The Credit Model

This model draws ultimately from the postal service (e.g., stamps). Customers budget for and buy X usage credits per quarter. Each use of SaaS consumes these until their budget runs to zero. They can distribute these credits for use internally however they desire. This “caps” costs but can leave businesses “in a lurch” if credits run out faster than expected.

This model is good for discretionary business applications (e.g., recreation/reward allowances and advertising click-thru’s)

The Tax Model

This model adds a standard overhead “tax” to a recurring operation. It is most well known in the credit card payments industry but has applications in many other “commodity” transactions. It is predictable. However, it requires high volume to avoid high taxation rates per transaction.

This model works best in places where the cost of the transaction is low vs. the value of the item transacted (e.g., eCommerce, HR payroll software).

None of these are ideal for all circumstance. However, each balances the benefits of SaaS’ flexibility with the “old fashioned” business need of predictability and control for specific business scenarios.

Disclaimer: I have been both a SaaS buyer and seller, using all of the models above – and many more that I would avoid like the plague. See my background for more information.

Note: If you liked this, you may be interested in Nine (Ten) Software Pricing Models Evaluated