Blog

Did you see the news that HP announced their foray into the public cloud space?  It is great to see another classical computing giant offer cloud services (Dell, IBM).

The blog post made by Emil Sayegh (VP Cloud Services) included a solid statement of intent:

“…our goal is to provide the next generation of cloud infrastructure, platform services and cloud solutions for developers, ISVs, and businesses of all sizes. We recognize that public cloud services should be open and transparent from end-to-end across APIs, infrastructure and software stack.”

This combined with Emil’s heritage as Cloud Computing GM at Rackspace may indicate a stronger desire to compete with AWS rather than the services-heavy IBM.  (Side note: an interesting IBM-HP comparison from a couple of years ago.

The biggest challenge will be the software  - the further up the cloud stack we go, the more software skills, technology, and experience is required.  This has not been HP’s traditional field of strength.  Although it will be interesting to see if/how the Autonomy acquisition could fit into the cloud mix.  HP’s definitely playing catch-up, so there will likely be more acquisitions along the way.

A big winner for this announcement will be OpenStack.  HP announced joining OpenStack in July and is basing part of their cloud solution on the open source technology.

This is all good for Xuropa - the more choice we have at the Infrastructure and Platform layers the better.  Our Intelligent Sales Engine™ will happily sit on top of any cloud and enable ISVs to deliver their software as SaaS.

Posted under Xuropa, cloud

The Economist this week published an article (Tanks in the Cloud) that talked about an attempt to fill in the cloud market knowledge gap left by industry analysts such as Forrester Research.  The problem the analysts have is that the further down you go in the Cloud stack, the less forthcoming companies are in divulging their revenue numbers.  Companies say even less about the number of servers they have in their data centers (which is where the tanks come in).

The 2010 revenue numbers of interest (see illustration) are SaaS (Software-as-a-Service) $11.7 Billion (Forrester Research); PaaS (Platform-as-a-Service) $311 Million (Forrester Research); IaaS (Infrastructure-as-a-Service) ~$1 Billion.

Cloud Layers with 2010 Revenues

The “$1 Billion” figure for IaaS comes from an extrapolation from estimates of revenues generated for Amazon by its AWS (Amazon Web Services) business.  Two estimates were used, one performed by Randy Bias of Cloudscaling ($500M to $700M), and the other by UBS ($500M in 2010, and $750M in 2011 - a tidy growth rate).

And the tanks? I’ll leave it to the article, but the method applied by Cloudkick (acquired by Rackspace) and Guy Rosen estimated Amazon to be deploying around 90,000 virtual servers per day in their East Coast region alone.  The estimate is a little on shaky ground, but “in the land of the blind, the one eyed man is king” right?

Anyway, that’s a lot of servers.  It makes you think about software vendors considering turning their data centers into clouds to make their software available in a SaaS model.  The private-cloud-made-public is a good way to start at this nascent stage of market development, but how does this scale as we project out?

Posted under cloud

Thanks go out to Richard Goering for his recent blog post about Hybrid-SaaS.  At the end of Richard’s post he thought a definition of the different layers of the stack would help, so this is a much simplified series of summary descriptions for each of the layers.

The Cloud Computing Stack

Starting at the beginning, below is the three layer Cloud Computing stack.  We start at the application level with the Software-as-a-Service (SaaS) layer.  I recently learned that the term was coined by David Thomas, (CEO and Founder of Intacct, now at TechAmerica) in a “gathering of the clans” at the salesforce.com offices in San Francisco involving Marc Benioff and a number of other early SaaS leaders in the early 2,000’s.  The objective of the meeting was to come up with a term to differentiate themselves from “ASP“s, but I digress. 

SaaS is the delivery of the end-application within a browser.  Next down is the Platform-as-a-Service (PaaS) layer and represents a collection of development tools, API’s, and resources used to create SaaS applications.  Finally, there is Infrastructure-as-a-Service (IaaS); a collection of (usually) virtualized compute, network, and storage resources.

Cloud Computing Stack

 SaaS Layer

This is the piece of Cloud Computing that we come into contact with everyday (every hour!?).  It is Facebook, Google Docs, LinkedIn, Virgin’s online booking app, Expedia, etc.  It is a remote application accessed and used via a common web browser.  There are no downloads, no installations, and no licenses to deal with.  Although consumer applications do not have Software License Agreements (SLA), many B2B (Business-to-Business) apps do have SLA’s, especially when deployed throughout an enterprise.

Implicit in the fact that SaaS is remote, and nothing needs to be installed - no servers and no IT required.  Two of the especially sweet reasons to go with SaaS.

Within each application there is the core functionality that delivers the value of the application.  The app engine, if you will.  This holds the secret sauce of an application, the core algorithms and differentiated functionality.  Outside of this, there is a varied collection of fairly standard components (see diagram below).

There are usually at least two interfaces or views of the app, and often there are more depending upon privileges .  An administrator view and a user view.  Below this layer is a collection of common services, such as Identity Management, Access Control, Analytics, etc.

All of these components need to be seamlessly integrated for usability and security purposes (why bolting something together around a Google Group, for example, doesn’t work).  Security needs to be integrated across the entire app to ensure functional and data integrity.

The entire app must be “infinitely” scalable.  Meaning that any number of users can start using the application at any given time.  In the bad-old days, in order to manage any spiky traffic, this meant leasing a whole mess of servers from a hosting provider.  Now we just develop the app on a scalable provider, such as Amazon’s EC2 and we’re good to go…as long as your credit card doesn’t max out

SaaS vs Client App Development

In my last blog post, I gave a collection of reasons why many enterprise software applications will have a hard time converting into a SaaS application.  The greatest technical reason is architectural - moving from a single-user client app (”single tenant”) to a mult-user server-based app (”multi-tenant”).  A Service Oriented Architecture (SOA) may help this transition, but there’s still a lot of work to do…in fact, the reality is, the endeavor will be a complete re-write.  (As a point of reference, I was talking to an Enterprise Software developer the other day, and he said his application had 11 Million lines of code…)

Also, the languages used are different - Javascript, Java, and php (or Python).  Thanks to all of the web startups out there, php and Python (”backend”) developers are hard to come by.  And so a move over to SaaS would imply a massive re-training effort.

I hope this was a useful summary.  It is in no way intended to be exhaustive.

If you know of any useful references, please add them in the comments.

Next up, Platform-as-a-Service, or PaaS.
Connect with me:

Posted under Xuropa, industry