Archive | February, 2011

IaaS and SaaS lead to PaaS

13 Feb

Most people currently portray the Public Clouds as a stack consisting of IaaS, PaaS, and SaaS.  Worse still, they try to define Private Clouds in the same way. In a discussion I had with Christofer Hoff@Beaker he accurately pointed out that this isn’t entirely the case, that they are all really Integrations.  This blog post was about three sentences in when a discussion broke out on Twitter regarding IaaS and ultimately where IaaS and SaaS converge – hint: PaaS.

IaaS and SaaS lead to PaaS

IaaS is becoming established by many Public Cloud providers by providing Virtual Machines, Block Based and File Based Storage, Databases and Key Value Stores, and several other core capabilities. As these capabilities become more sophisticated and their complexity increases, the drive to abstract and re-simplify pushes IaaS toward PaaS. IaaS is beginning to also take root in Private Clouds (Enterprises) where there is a motivation for more automation and self-service in an attempt to drive more efficiency. What Private Cloud providers (I’m thinking of IT) will find is that they are unable to achieve the same levels of efficiency that Public Clouds can. The difference between Public Cloud IaaS and Private Cloud IaaS efficiency isn’t entirely based on scale as you might initially think. The disparity is also driven by the storage philosophies that they follow or rather the difference.

Public Cloud IaaS is driven by very cheap and very scalable storage using software based redundancy with many replicas of data (think multiple copies on JBOD). Private Cloud IaaS in contrast is driven by highly available, fault tolerant, hardware redundant disk arrays (think SANs). This difference in storage methodology translates into a difference in Platform Methodology, Applications Methodology, and Operations Methodologies. Data is king and the assumptions that are made around how data is persisted and retrieved drives decisions about platforms, applications, and operations.

When Private Clouds embrace some of the newer approaches in storage, they will also embrace change in their Platform, this is where PaaS enters the picture in a big way. PaaS will also be pushed by applications developers because of the increases in productivity and efficiency that it brings to Enterprise Development Organizations. The changes to the Enterprise Development Orgs mean changes to Application Design Methodologies. These changes will drive IT to make changes as well because previous Operations Methodologies will no longer work (I’m looking at you traditional ITILv3). There will also be deep security implications to all of these changes, however this will neither make security better or worse, just applied differently than it is presently.

We’ve covered the IaaS angle and how it pushes toward a PaaS centric world, but what about SaaS? I find it interesting that SaaS has been with us for 10 years now, yet many people are just realizing its value. The defacto example of SaaS is Salesforce.com. Virtually every article that talks broadly about SaaS mentions them, mainly because almost everyone has heard of Salesforce and has probably interacted with it at some point in their career. Public Cloud SaaS has several issues that it struggles with, two of which are the need to maintain a shared infrastructure in order to keep costs low but still keep customer data separate. The second issue being the need allow customers to customize the solution to meet their needs (this could be through integrations, add-ons, or other applications). Making this work if you are simply delivering pure software as a service is difficult if not impossible. This has led Salesforce and other providers to slowly transform into more of a Platform that offers Software and less of a traditional or pure Software as a Service solution.

Public SaaS Cloud moves toward PaaS because of customer demands for isolation and customization, but what about Private SaaS Clouds? Private SaaS Clouds are more about the delivery and management of the software by IT. This pattern of an Enterprise being its own provider or contracting to a Hosting Provider for these services will still drive them to want capabilities that are not out of the box. This drive will lead them down the PaaS path as well.

PaaS no matter what it ends up looking like is much closer to what the end state looks like than IaaS or SaaS.

Service Energy – Complimenting Data Gravity

2 Feb

It has been a while since I posted anything referring to Data Gravity.  While Data Gravity is interesting and can explain many motivations of Cloud Companies and their Data Services, there are other influential forces at work.
Service Energy

What am I referring to as a Service in this case?  Any code or logic that has been deployed by a provider to expose a resource.

Examples include:

  • APIs
  • Message Queues and Buses
  • Automation, Scripting, and Provisioning Interfaces
  • Web Services
  • Many more…

When resources are externalized, this is what enhances the value of Data and helps increase Data Mass and Data Gravity. As a Service is used more frequently, the amount of energy it is emitting increases in our analogy.  The emitted energy has effects just as it would in Physics.  Service Energy has the ability to assist in Escape Velocity as well as increase Data Gravity, all depending on what the Service Energy is doing.
Service Energy shows motivations in Clouds for specific behaviors such as:

Why Salesforce acquired Heroku – (Heroku is indeed a Ruby PaaS, but it was beginning to bring in SERVICES from outside which increased its Service Energy)  Salesforce needs this in the Ecosystem, just like it needed to create Database.com to help increase it’s Data Mass and therefore it’s Data Gravity.

Why Amazon created SQS and SES (These are services that encourage additional consumption of Compute but more so amplifies the amount of data (Data Mass)

It should be noted in the picture above that the Data is made accessible through a service which is why it has Service Energy around it, which should be distinguished from Data Gravity. Remember, Service Energy does NOT attract, but can amplify.

Service Energy also can be used for Escape Velocity.  By properly architecting applications and even Service Oriented Platforms, the Data Mass can be spread across many providers (and even sources inside of those providers).  This provides looser coupling between the App and a specific Cloud, which gives more flexibility.  The trade-off is that this design is more prone to service interruptions, latency, and bandwidth constraints.

There is much more to be said about Service Energy in the future including exploring other effects it has with more IaaS centric solutions.