SolidNode

Lately I have observed significant movement in two transformational trends – adoption of REST over SOAP and proliferation of non-relational persistence options. These two trends complement each other and they are likely to cause disruption sooner than later.

The enterprise software that required complex transactions, monitoring, and orchestration capabilities relied on the SOAP-based architecture and standards to realize their SOA efforts. The consumer web on the other side raced towards embracing RESTful interfaces since they were simple to set up and consume. There are arguments on both the sides. However, lately the market forces have taken the side of REST even if REST has significant drawbacks in the areas such as security and transactions. This once again proves that a simple and good enough approach that conforms to loose contracts outweighs a complex solution that complies to stricter standards even if it means compromising certain critical features. The web is essentially an unreliable stateless medium and any attempts to regulate it is less likely to work in our favor.

Many argue that the self-describing standards for SOAP are its strength over the RESTful services that lacks such features. However designing a RESTful service is fairly trivial since it allows to learn and experiment by being iterative unlike a relatively complex upfront learning process associated with the SOAP-based architecture. There has been a flurry of activities in the messaging middleware by Google that makes these RESTful interface even more compelling. This includes Google Wave Federation and PubSubHubbub. The developers are more likely to prefer these messaging protocols against SOAP and that would mean more RESTful APIs in the Pushbutton Web. Easy consumability reduces the initial adoption barrier and that’s the key to success in many cases.

Since I last blogged about the continuum of the database on the cloud from schemaless to full-schema new persistence options have emerged such as RethinkDB and HadoopDB and many debates have spurred questioning the legacy of the RDBMS. For a cloud-like environment the statelessness, ad hoc persistence design, and instantaneous horizontal scale go well with the RESTful architecture. The growing popularity of SimpleDB and CouchDB along with many discussions on how to achieve CRUD with REST signal that the persistence is becoming more RESTful and schemaless.

I was convinced quite some back that REST was certainly the future for the consumer web but the latest trends have made me believe that the REST will see its adoption in the enterprise software accelerated much sooner than I had originally expected. This is like Java and Internet; the organizations embraced Java and the Internet at the same. The same will be true for the cloud and REST. When the companies consider moving to the cloud they will reconsider their SOA and persistence strategy and will likely adopt REST and alternate persistence models.

The cloud might be the last nail in the SOAP coffin.

Original Post:
SOAP may finally REST

Popularity: unranked [?]

An infrequently talked about, but very important aspect of cloud computing performance is ‘oversubscription’.  Oversubscribing is the act of selling more resources than you actually have to customers on the assumption that the average usage will be equal to or less than the actual resources on hand.  This is the de facto practice within the hosting and service provider market and has been from the get-go.

For example, typically most Internet Service Providers (ISP) oversubscribe their backbone bandwidth.  You won’t notice because most of the time you’ll get your full bandwidth.  Why?  Because even during peak traffic times not everyone is using the network.  Perhaps many or most of the folks in a given area might at any one time and service providers try to develop a subscription model that is as efficient as possible, giving most users their full bandwidth, most of the time, while allowing the provider to keep their costs down.

What happens when a service provider is wrong?  Ever been to some kind of major event where a huge number of people converge in a very small area?  Have you been unable to get or receive cell phone calls?  That’s what happens.  Even telecommunications companies and wireless providers oversubscribe.

Understanding Subscription Models
So, if oversubscription is the de facto standard and if it’s done improperly it could affect your cloud deployments (cloud user) or bottom line (cloud provider), let’s look at a simplified example of building a subscription model.  The following image is an Excel spreadsheet that models CPU subscription rates [1] (click through to download the original Excel spreadsheet):

For this example, the very first row in the table represents a baseline.  We’re assuming:

• single physical server with 16 physical cores
• a subscription ratio of 1-1 (normal subscription)
• an allocation of 1 virtual CPU (VCPU) per VM
• 1 VM total on this physical host (this is our baseline)
• The VM is using 100% of it’s VCPU

For the baseline only, ignore ‘Effective Allocated VCPUs’ and ‘Effective VCPUs Used’.  These are artifacts of the formulas I’m using and I didn’t remove them before generating this table.

On the right hand side you’ll see that in our baseline model our VM receives 1 minimum physical core of usage, can burst to a maximum of 1 core, and averages 1 core of usage (because it’s using 100% of it’s VCPU).

The rest of the pink rows following our baseline are all ‘normal subscription’.  Meaning the cores are not oversubscribed.  For example, row 3 (2nd after the baseline) shows us the effect of allocating 4 VCPUs per VM.  This means we can only have 4 VMs max on that server without oversubscribing.  Each VM gets a minimum of a single physical core and can burst to 4 cores.[2]

More interesting are the following peach colored rows that show oversubscription models.  Taking the very first row where we’re oversubscribing at 2-1, we’re effectively saying: we will sell 32 VCPUs for our 16 physical CPU cores.  At 1 VCPU per VM, we can now fit 32 virtual machines on a single physical server (2x our normal subscription rate at it’s best).  We now know:

• Each VCPU gets a minimum of 50% (when running at 100% utilization for all VCPUs)
• The most each VM can consume is 1 VCPU (we only allocated 1 each)
• Running at an average utilization of 75% per VCPU, each customer gets 2/3rds of the VCPU they bought

This is a very crude model.  It doesn’t take into account mixing different size VMs on a single physical host and a host of other factors [3].  What it does show you is that your cloud hosting provider’s oversubscription model can directly impact your cloud applications hosted on their infrastructure.

Remember, oversubscription can happen for disks, memory, CPUs, and network bandwidth.

Oversubscription in Clouds Today
Most cloud providers oversubscribe cores and disks currently.  One of the few exceptions that I’m aware of is Amazon’s EC2.  My understanding is that they do not currently oversubscribe cores, but they almost certainly oversubscribe disks, particularly on small instances.  This is from inside knowledge.  You will find folks who are measuring ‘stolen time‘, but I suspect this has to do less with it being allocated to other VMs and rather more likely being stolen by the host itself[4].

The moral of this story?  Proper cloudscaling requires understanding how oversubscription works.

If you’re a cloud hosting provider, PLEASE do the math; don’t fly by the seat of your pants.  Figure out the sweet spot where you can oversubscribe resources, but give your customers (on average and for peak loads) good value for their money.

If you’re a cloud user, you need to recognize that your application’s performance may be impacted by how your cloud provider does oversubscription.  Don’t be afraid to ask how they model their oversubscriptions.  Don’t be afraid to measure OS performance yourself.  If you’re using Linux, make sure you measure how much stolen clock time you see.  Regardless of your platform, if consuming cloud storage, instrument your application so you can see when there is variability in or increased latency of that storage [5].

---

[1] I am not a real business analyst, I just play one on TV, so take this chart with a grain of salt.  A big one.
[2] I think my formula broke here for average cores.
[3] To have a proper model, you would need to have a combinatorial model that took into account RAM, CPU, disk, and networking; BTW, Xen doesn’t allow oversubscribing RAM, but VMware does.
[4] Elastic Block Store (EBS) and similar are not ‘free’; since EBS is almost certainly iSCSI-based, any significant usage of your EBS volumes will require not inconsequential CPU usage by the physical host server.
[5] If you’re a Rails user, check out NewRelic, who have some tools in this regard; if you’re not, take a look at collectd or Reconnoiter to do it yourself.

Original Post:
Subscription Modeling & Cloud Performance

Popularity: unranked [?]

A clever choice of the right architecture on right infrastructure has helped the SaaS vendors better manage their operational infrastructure cost but the SaaS vendors are still struggling to curtail the cost of sales. As majority of the SaaS vendors achieve feature and infrastructure cost parity, reducing the cost of sales is going to be the next biggest differentiation for the SaaS vendors to stay competitive in the marketplace.

Direct sales model is highly ineffective and cost-prohibitive for the SaaS vendors as it does not scale with the volume business model that has relatively smaller average deal size. The role of the direct sales organization will essentially get redefined to focus on the relationship with the customers to ensure service excellence and high contract renewal rates in addition to working on long sales cycles for large accounts.

How can a SaaS vendor reduce the overall cost of sales to maintain healthy margins and growth?

This is a difficult nut to crack. There are no quick fixes. There is no easy way to optimize the tale end of the process without holistically redesigning the entire SaaS life cycle.

Self-service demos to “self-selling” trials:

Fundamentally the direct sales model for an on-premise software sales has been all about initial investment into the right demos to model customer scenarios and align the sales pitch to match the solution needs. The SaaS vendors moved away from this model as much as they could and replaced it with the self-service demos or trials. However these demos are not “self-selling” and still requires intervention from the direct sales people at various levels.

The SaaS vendors need to move from self-service demos to the self-selling ones that are not only fully functional out-of-the-box but also articulate the solution capabilities implicitly or explicitly. The demo is not just about showing what problems you are solving but it is also about how well it maps to the customers’ pain points. It is like buying a hole and not a drill. The demo and the product should scream out loud the value proposition without making customers go through a webinar or a series of PowerPoint slides.

Customer acquisition to customer retention:

SaaS companies have traditionally focused their sales and marketing budget on customer acquisition against retention. While customer acquisition is a necessity the increasing SaaS competition could result into the current customers ditching the vendors. Customer support is the new sales model. Design your customer support organization and operations to retain customers. Don’t let the contract renewals slip through the cracks.

Your customers are the biggest asset that you have. Market new solutions to them as an up-sell. One of the powerful features of a SaaS platform is to be able to integrate and push the new products effortlessly to the existing customers and have them try it out before they start paying you. Modernize your internal tools to track the usage analytics to better understand your customers, sales activities and effectiveness of the marketing campaigns. You have a problem if you cannot tell which customer is using what, who are the right partners, who needs training and support etc. If you haven’t lately looked at the tools that your sales people use this is the right time. I would not expect a SaaS vendor to reduce the cost of sales without empowering the sales force with the true customer, competitior, and partner intelligence.

Low-touch persuasions to hi-touch interactions:

Low-touch one-to-one selling does not scale. Replicate the Avon model. Design a great ecosystem of your channel partners to whom you can pass on the cost of sales. Align the incentives and encourage the partners to sell but ensure the customer support and overall brand integrity. This strategy would require an extensive partner program with sizable investment in training and tracking what and how the partners are selling but this investment will go long way.

Reserve the direct sales force engagement for large hi-touch CIO type deals where you are required to go whole nine yards before you get a contract. The key is to have a highly variable sales force and extremely efficient compensation model to deal with a variety of prospects and customers. One size does not fit all.

Low-barrier adoption to zero-barrier productivity:

The SaaS model pioneered the low-barrier adoption empowering the LOB to sign up and start using the software without an approval or help from the IT. Eliminate any and all barriers to further penetrate the adoption. Do not enforce upfront credit-card requirements and even skip the registration if you can. Let the customers use the software with the minimum or no information up front. Demonstrate value when asking for more information e.g. Picnik lets you manipulate image in any way you want but would ask you to register if you want to save images. There should be no paper work whatsoever, not even a physical contract. Allow customers to bring in the content from other sources such as Flickr, Facebook etc. Allow the customers to have access to a live sandbox as a step before the dedicated trial. Starting from a blank canvas could be a hindrance to evaluate a product.

Original Post:
SaaS 2.0 Will Be All About Reducing The Cost Of Sales

Popularity: unranked [?]

There are many sources that feed my insatiable need for cloud computing and infrastructure news.  One of these that I have been following for a while I wanted to share with my readers.  It’s the Infrastructure 2.1 Newsletter from the Internet Research Group (IRG) and you can sign up here.  I’ve been following John Katsaros and Peter Christy regularly and their newsletter is a great source of information.

With permission I wanted to reprint a few choice nuggets from the latest issue.

Virtualization Wars
IRG on VMware vs. Microsoft:

The Virtualization War — At the Microsoft Virtual Analyst Meeting, Muglia chirped happily that he was gaining hypervisor market share every day. Although we think that must be true, we couldn’t get any of the underlying data so we couldn’t de-spin it. As we continue to muck about in the Cloud and Utility Datacenter, it’s pretty clear that’s still all about VMware. So what does the future portend? I continue to think that Microsoft is strongly in the game. The most recent financial reports give an interesting perspective on this. VMware has suffered a year of quarter-over-quarter declines in license revenue, buffered somewhat by rising service revenues. This isn’t necessarily a bad report, but at the most recent report Microsoft reported that System Center – the System Management tool that in the end is probably what VMware competes with – grew at a very healthy year-over-year rate of 30% (independently we have heard that it is about a $1.5B/year product. That suggest that System Center is significantly bigger than VMW (comparing apples to apple if that is possible) and growing much more rapidly. As we said, it would probably be premature to count Microsoft out now.

The IRG folks have a fairly good relationship with the folks in Redmond, so I’m inclined to take their number of 1.5B for Microsoft’s System Center at least somewhat seriously.  If true, it’s clear that Microsoft is gaining some traction in the infrastructure automation and data center management space.  It also means that Microsoft might be the only folks with a shot at displacing VMware’s dominance of virtualization in enterprise data centers.  One main takeaway for me was: the hypervisor (ESX vs. Xen) isn’t where the real battle is.  It’s in the tools that manage the hypervisors.  The technology on which clouds are built, essentially.

Real Cloud Value
Another interesting nugget from their interviews with a number of cloud ‘experts’:

The Cloud (Dessert Topping or Floor Cleaner)? John and I have done a lot of interviews with Cloud “experts” over the last few months (this is the fun part of our business, hunting down and talking to really bright people). On the one hand, a lot of the analysis bandied about is malarkey (to be polite). Enterprises won’t jump into public clouds to save buckets of money any more than we’ve all given up our cars to drive Hertz Rent-a-Cars instead (shouldn’t they be a lot cheaper for the same reasons, huh?). On the other hand, we’ve been talking to many of the most successful ventures using Amazon (primarily, and other Cloud providers) and the stories are very interesting. There seem to be two important takeaways for me: (1) The cloud is software gurosity unleashed. A team of brilliant programmers and system architects can make incredible things quickly when unfettered from the nasty bits of buying and running the hardware infrastructure; (2) For speculative ventures, it’s hard to beat the economics of pay-as-you-go

This jibes with my own experience and belies the typical cheerleader mentality of some cloud advocates who would have you believe that ’scaling’ is non-trivial and the cloud is some kind of magic panacea.  I particularly like this part of the quote above: A team of brilliant programmers and system architects can make incredible things quickly when unfettered from the nasty bits of buying and running the hardware infrastructure.

This is really the nut.  Despite the hype around cloud computing, the initial set of early adopters on various clouds are, by definition, those with a higher than average set of skills or, at least, a certain level of tolerance for complexity.  As cloud computing is adopted more broadly, the set of cloud tools and the maturity of clouds will have to improve in order to increase the pace of adoption.

Microsoft vs. Amazon Pricing
And, finally, a nice little comparison of Amazon versus Microsoft cloud pricing, which I haven’t seen elsewhere:

Keeping It Simple — Even just ten years ago you’d have thought it crazy that we’d be talking about 12 cents an hour for a server. Last week Microsoft announced its pricing model for Windows Azure making it clear that the company will play a very aggressive role to quickly develop usage once its cloud services become available. The table below compares Microsoft Azure’s pricing to Amazon’s cloud computing prices. Microsoft’s pricing is simpler but Amazon’s pricing has two years of experience behind it which account for it being more nuanced. The two charts below compare Microsoft and Amazon pricing for data transfer out of their Clouds. Microsoft is clearly being competitive in the small to medium categories which probably is illustrative of their overall strategy.

Comparison chart:

	Microsoft	Amazon
Compute	$0.120/hour	$0.10/hour to $1.20/hour depending on CPU and O/S
Storage	$0.150 / GB-month Storage Transactions = $0.010 / 10K	$0.100 per GB-month $0.100 per 1 million I/O requests
Bandwidth	$0.100 in / $0.150 out / GB	$0.100 in / GB Data Transfer Out steps down from $0.170 to $0.100 /GB monthly usage.
Storage	SQL Azure Web Edition – Up to 1 GB relational database = $9.99 / mo Business Edition – Up to 10 GB relational db = $99.99 / mo	S3 $0.150 per GB – first 50 TB / month of storage used – ranging to: $0.120 per GB – storage used / month over 500 TB
Data Transfer	$0.100 per GB in $0.150 per GB out	$0.100 per GB – all data transfer in $0.170 per GB – first 10 TB / month data transfer out – ranging to: $0.100 per GB – data transfer out / month over 150 TB

Diagrams showing Data Transfer pricing:

Summary

Highly recommended you sign up for this news letter!

Original Post:
The Infrastructure 2.1 Newsletter

Popularity: unranked [?]

There will soon be two major paths for cloud computing providers: commodity and premium.  If you read my series, Cloud Futures, you’ll know that I broke down cloud service providers into three major categories: service clouds, consumer clouds (previously ‘commodity’)[1], and focused clouds. In retrospect I realize now that there are possibly four, not three major categories. The missing category is premium enterprise clouds. Previously I had lumped these under focused clouds, but I now realize that, in fact, there are likely to be so many of these that they deserve their own category. I’ll go even further and suggest that in terms of markets targeted, there will really only be two ends of a spectrum: enterprise and non-enterprise.

Most clouds will fit towards one of this spectrum or the other. In essence, you’re targeting small businesses (startups, SaaS providers, and SMBs) or you are targeting larger businesses (SME or Fortune 2000). The former are extremely cost conscious while the latter may have a number of other equally important drivers, such as security (e.g. VPN access), high availability (HA), SLAs, application portability without modification[2] and similar. Clearly large enterprises will consume services at both ends of the spectrum, but they will have many use cases (mostly ‘production’) that can only be serviced by a premium service running VMware’s forthcoming vCloud product.

This means we will have a large bifurcation in the cloud computing space with two very different kinds of solutions. Clouds will either target commodity customers or premium customers.  Very few clouds will actually fit in the middle of this spectrum initially, although I expect providers on both sides will grow towards the middle.  In quite a few cases (AT&T and Rackspace come to mind) cloud providers will build two offerings at both ends of the spectrum, but we haven’t seen this quite yet.

Premium vs. Commodity

Ultimately, commodity clouds will be forced via pricing pressure to continue to drive down capital expenses and operating costs.  As we can already see in the public cloud space, providers have largely standardized on the Xen open source hypervisor.  This is the de facto standard because it is free.  In contrast, premium enterprise clouds will necessarily spend more on their infrastructure to provide advanced features like HA.  Their pricing will reflect this, but it also means they will use VMware’s products and hence have unique opportunities for integrating with internal clouds at large enterprises (more on this below).

This table summarizes the differences.

	Commodity	Premium
Focus	Price	Value
Hypervisor	Xen	VMware ESX/vSphere
Pricing	$	$$$$
“Enterprise” Features	No	Yes; lots
Your App Needs Changing?	Yes	No

Enterprise Clouds Are Already Here

If you were paying close attention this year, you’ll have noticed that both Savvis and Terremark are working on or have delivered enterprise cloud offerings.  There are many  more on the way.  These providers are delivering VMware-based platforms specifically for enterprise customers and pricing reflects that[3].  Terremark even labels itself ‘The Enterprise Cloud’.  I had hoped to release a full review of Terremark, but due to time constraints haven’t been able to complete it.  If you click on the screenshot to the right it will take you to a set of Flickr photos that are an extensive tour of the Terremark Enterprise Cloud product.

What’s most interesting about this is that two major players have entered into this space and at the same time VMware’s vCloud is unreleased.  Nor are there any other shrink-wrapped software packages for building a cloud based on VMware.

VMware’s Dominant Position for Building Internal Clouds

But why VMware?  What’s so important about it?  For those of you who may not be aware, VMware’s enterprise-class hypervisor (ESX) is the de facto standard inside the enterprise, in much the same way the Cisco routers & switches are a standard.  This means that as enterprises move towards building internal clouds (an inevitability), they will be more likely to build clouds based on VMware’s ESX, which they are already comfortable with.

A-ha! Surely there is a startup or major player who has already delivered a software offering that allows enterprises to build their own internal clouds?

No. There is no credible contender to VMware’s crown.  Even though they did not see cloud computing coming, even though they are a large organization and slow to move, there is still not a single credible contender with a released product that manages the VMware ESX hypervisor and allows you to build a real self-service internal cloud.  Nada.  Zip.  Zilch.

There are some prospects like Platform’s ISF[4] that could be contenders, but by the time they are released in the wild, VMware’s vCloud will also be released.  The window of opportunity for making significant inroads into the enterprise is closing quickly[5].  Once VMware’s vCloud is released, who will risk averse IT managers and CIOs in enterprises go to?  A new player or someone already trusted and embedded like VMware?  There is no doubt.  They will largely select vCloud unless VMware fails to execute.

Can VMware Fail to Execute?
Is it possible for VMware to fail to execute in it’s sweet spot?  It’s area of expertise?  Yes.  Is it likely?  No.  If you look at the DNA of the business they already have the kinds of talent necessary for building a strong product in their acquisition of Akimbi, the folks upon whom the VMware Lab Manager product was built.  That team already knows how to build a self-service portal and a large scale VM deployment system including scheduler as these were integral for the lab manager product.

In other words, the writing is on the wall.

The Power of Internal + External Clouds
For many smaller business, moving everything to the cloud will always be a very compelling solution, but for the enterprise it will never be acceptable.  For various reasons (regulatory, political, legal, and others) enterprises must maintain a certain amount of infrastructure.  Also, I’ve heard fairly compelling arguments that large enterprises have sufficient scale to build and operate their own clouds at a cost advantage to external clouds.  Regardless, some capacity will reside outside of the firewall.

The usage of external clouds will largely be dictated by use case and in order for enterprises to derive maximum value from both internal and external clouds they will want a single internal portal that manages both.  They will want minimal friction for internal customers to be able to pick the best cloud for the job/cost.  It will also be important to allow some amount of portability (moving VMs and their workloads across the firewall).

While this doesn’t require a VMware hypervisor on both sides of the firewall, it will be greatly facilitated if that is the case.  Tools written against the vCloud API will likely work with vCloud-based external clouds without modification.  There is simply far too much synergy possible once both internal and external clouds are based on the same cloud platform.

Summary
There will be two paths for clouds: premium & commodity.  Premium clouds will focus on the enterprise and delivering value they are concerned about.  Commodity clouds will largely be forced to compete on pricing and features irrelevant to the enterprise.  VMware’s vCloud will be the dominant player behind the firewall because there is no credible contender.  The synergistic effects of internal & external clouds being based on the same vendor’s software will provide powerful and compelling reasons for enterprises to adopt those external clouds.  Enterprises will use commodity clouds, but mostly for batch processing and non-production workloads that are pricing sensitive.  The bulk of enterprise cloud spending will be on vCloud-based public cloud providers.

---

[1] I realize, also in retrospect now, that I should have chosen a better name than ‘commodity clouds’.  To avoid confusion in this article, I’m going to call them ‘consumer’ clouds.  Any suggestions?
[2] This is still pretty much impossible for Amazon to do for many architectures.  When you go to the Amazon or Google ‘clouds’ you’re making a choice to port your application.  Some clouds, like GoGrid with their CloudCenters, do make it portability easier.
[3] I didn’t get it nailed down for this article, but if memory serves Terremark’s entry-point offering is about $2,150/month for 10 cores, 10GB RAM, 100GB storage divided up however you like across up to 10 servers.  You can add more of each incrementally and there are pricing discounts on volume.
[4] Platform has been delivering grid solutions, very similar to technology that powers today’s clouds, for many years and has great DNA to build a compelling offering.
[5] Honestly, it’s probably already a done deal.

Original Post:
Bifurcating Clouds

Popularity: unranked [?]