Hello Webgrrls. More greetings and info from Septemberâ€™s Interop conference.
In this post I will try to break down the following: the meaning of SaaS (Software as a Service) and, briefly PaaS (Platform as a Service) and IaaS (Infrastructure as a Service).
One track of the Interop NY seminars dealt with SaaS, and I thought it would be a valuable complement to the seminars I attended on Cloud Computing, so, there I was. And here we go.
To start, Software as a Service.
An application that is delivered through the SaaS model is typically done over the internet by a third party with no opportunity to bring the application in-house. As a user/subscriber, you use that providerâ€™s application.
The other key to all SaaS is a variable, pay-as-you-go pricing structure, or on-demand pricing, a 21st century morph of just-in-time inventory strategies. Salesforce.com, Netsuite, and similar CRM and eCommerce applications come to mind. SaaS solutions increasingly offer real time analytics and self-provisioned toolkits, and have gained both traction and credibility in areas like accounting software, financial applications and supply chain management.
The notion that we are moving toward a time where enterpriseâ€”in the form of various SaaS applicationsâ€”takes place in the Cloud spurred Interop musings on the transformative power of innovation, detailed in books like Electrifying America: Social Meanings of a New Technology, 1880-1940 , as well as its â€˜unintended consequences,â€™Â chronicled in Why Things Bite Back: Technology and the Revenge of Unintended Consequences.
If cloud computing is commonly referred to as â€˜on demandâ€™ computing, SaaS is the reason why. At Interop, the discussion often turned on the transformative power of SaaS: e.g., the potential for nearly instantaneous scalability–sudden spikes in demand can be accommodated via multiple servers spread across multiple data centers–and burstability, the ability of the system to supply bandwidth to accommodate sudden need.
The deployment of SaaS can also yield â€œunintended consequences,â€ among them, unclear pricing structures, uncertain dependability and security issues.
To address these issues, an entire panel discussion was devoted to Service Level Agreements, or SLAâ€™s. A Service Level Agreement may be the most important cog in the whole SaaS wheel, as it sets the parameters of your dealings with your SaaS provider.
This is the point at which Software as a Service and Infrastructure as a Service overlap. Deployment of resources such as networking equipment, servers, and data center facilities are key determinants of pricing and scalability, and the SLA addresses the nuts and bolts of theseâ€¦nuts and bolts.
In any SLA it is important to ask key questions, to determine the degree of infrastructure transparency, and to get the answers in writing:
Can I always access my data? This is most important when considering migration from one provider to another. If you canâ€™t get to your data, you canâ€™t migrate it.
Specify availability: When will my employees/customers be able to access my data and how long will it take them to do so? The SLA might be framed: â€œBank tellers will be able to log in from all North American branches 99.5% of the time in 8.4 seconds.â€
How do I access your helpdesk?
Where are my servers located? You discover that most of your servers are located on a volcanic island that is due for its once-a-millennium eruption. This is not good news.
How do I dispute my bill? SLAâ€™s should have concrete provisions for compensation during unexpected downtime.
Does this application comply with the law throughout the world?
When the software is upgraded, can I keep users on the older version while training them on the new?Â Smooth transitions are key.
And perhaps most interesting: What privacy guarantees do you have in place? SaaS providers based in the United States are now subject to the Patriot Act, and thus subject to unannounced security audits. Some companies have chosen, rather than subject sensitive data to government scrutiny, to seek out SaaS providers in Canada or Europe. And there will be snafus in the most sophisticated security operations. Ericka ChickowskiÂ recently explored security concerns raised by clients of none other than Google Apps.
Finally, Sam Johnstonâ€™s Cloud Computing Bill of Rights may provide a good guidepost for users of SaaS when it comes to creating a sound SLA.
Another great panel discussion at Interop was called â€œUsing SaaS to Make Good Products Great.â€ The subject was best illustrated by Rob Donahue of Tom Tom. Tom Tom has added an SaaS component to its GPS system, and salespeople using their GPS] can now access customer databses. Tom Tom will then guide them to the customer. An elegant mashup.
Which leads us finally PaaS, (Platform as a Service), the very soul of mashups. PaaS is identifiable to all of us in terms of social networking and other Web 2.0 applications. We have entered the era of the Web as Platform.
We upload to YouTube or change our Facebook profiles, and no external applications are needed drive these changes.
For developers, PaaS means something even better: they can debug and test in the same environments in which the software will be deployed.
In his white paper on PaaS, Dion Hinchcliffe states:
â€œNow that the Web itself is as available and standardized as the electrical grid or the telephone system, it is capable of including all the systems and environments comprising the software life-cycle: prototyping, developing, testing, deploying, and hosting. This changes the entire process of creating a Web application. In short, using the Web itself as the application development platform is the next logical evolution of software and computing â€˜in the cloud.â€™ ”
â€œYou develop your app through the browser, then deploy your app through the browser and map the app to your domain / URL (or embed the app in your site) – It’s your app. Oh, and you get IE, Firefox and Safari cross-browser compat taken care of too – you build your app once and it just works in these three browsers. Sweet.â€