Thursday, May 21, 2009

What is SaaS?

What is SaaS?

Some time back I came across this question in an interview; with less knowledge I guessed its “its and bits”. After diving in to several articles, groups, forums, discussions, reviews, and thoughts; and an “attempt” to provide my own SaaS based custom email app made me learn a lot. Following are the few points which are based upon my short experience over SaaS and thoughts from the industry experts.

SaaS is a new delivery model where companies pay for using the software. Usually, SaaS applications are hosted by the vendor itself. This means, lower total cost of owner-ship and quick/rapid return on investment. Its multi-tenant architecture, is like living in an apartment with your own private space.

Some of the features that SaaS offers:

  • SaaS eliminates the effort associated with updates and maintenance.
  • Software is distributed over a server, and is access through a web browser.
  • There are no software updates to install, and no backup plans are required: the SaaS vendor maintains redundant backups of all systems and data.
  • SaaS is pay per user per month(or year) model, that usually resides on Cloud Platform. Note that, SaaS is not Cloud, but a Cloud can contain a SaaS app.
  • Provides the level of granularity in options/customization.
  • Though “On-Premise” is not truly a SaaS application, the software installations provide the ability to customize an application for a customer’s specific needs.
  • The medium of communication is the internet, so the “performance-hit” is inherent. But this really depends upon the physical network and the type internet service provider being used.
  • Usually a SaaS vendor maintains servers(farm) as part of their network operation services; and therefore the application processing is distributed throughout the network and is optimized, this gives efficiency, higher up-time, and dependable performance.
  • Rapid and responsive development and introduced the methodology of rapidly releasing functionality, that utilizes Agile or XP etc; this enables to be more responsive to customer requests and technological advancements.
  • Since the services are bought, therefore this lowers the total cost of ownership; and reduces unpredictable costs, meaning less risk for the customer. As a result, risks can be avoided, risk is reduced, or transferred.
  • SaaS apps are by nature centrally managed, which means no more patch installations.
Illustration by a glance to cloud


Who needs SaaS?

Since SaaS’s primary platform is Cloud; the architecture of cloud apps better suits to enterprises.


Who are SaaS Providers?

Some that I can count on fingers are,

* Salesforce.com and SugarCRM are practical running application of SaaS apps.
* Linkedin is another application based upon SaaS model.
* Cleartext Systems have their products Clearspace 2.5/Jive SBS, and Axigen - Secure Mail Server.
* And Ubuntu’s Enterprise Cloud (UEC Blog)

Other well known SaaS providers are Google, Microsoft, QuickBooks Online Edition, and WebEx. Some are providing installable SaaS application cloud platform

Concerns:

Two of the concerns that I believe are associated with SaaS; One, the security is the major concern in SaaS applications; a SaaS vendor only knows what's "generally" best; that is, one customer's definition of secure may be another's wide open to attack. And secondly, not all vendors provide service level agreements.

I believe good/emerging SaaS providers should add a trial period before purchase of the service; so a customer would know that the application is already running on the vendor servers; those who do not plan provide such trials should provide a solid explanation.

The multi-tenant architecture of the on-demand model means that everyone runs on the same code base, and often the same instance. This would inherently force the vendors to offer a variety of configuration options so that customers can adapt their view of the application to their customized business needs.

Good service delivery management infrastructure is important, because this requires a need for robust, mature network/application server setup.

And basic/pre-requisite services like providing user provisioning, service level monitoring, reporting, ticketing and tracking, versioning, server load balancing, then not only the vendor is not serious about software-as-a-service, but also is not in a position to guarantee quality of service.

It should provide APIs that comply with web services standards; so that it would be extendable, scalable, designed to make sense from a business point of view.

While reading I came across ZDNet’s Phil Wainewright who seems pretty much optimistic about SaaS and its future:

I can see parallels with a 128k hobbyist microcomputer that a large computer company introduced twenty-five years ago called the IBM Personal Computer. It was targeted at small businesses and hobbyists and was expected to sell just a hundred thousand units or so. Instead, it sold millions and spawned an industry. Sometimes the stuff you build for the little guys turns out to be just as useful for all the big guys too.


References:
* SaaS Google Group

* AlertLogic Blog
* OnDemand BusinessObjects
* SaaS Subscriptions

Tuesday, May 19, 2009

DTD v/s XSD: And What is DSD?

DTD v/s XSD:

Since I have looking into the XML schemas and validators, I was wondering about the differences between a DTD and XSD. Which one would we use when? And why?
Following are a couple of differences that I am able to conclude.

Sample Bookstore.XML

Data type definition(DTD):
• DTD provides a basic grammar for defining a document(HTML/XML/etc); its elements, attributes, their nesting and ordering.
• Namespaces cant be defined in DTD
• Hard to extend once written
• The language to define a DTD is called MNF; I forgot but it’s like Markus-Naum language.
• Requires a specific parser
• No builtin data types
• Matured/proven industry standard and is been in the industry for a while now
• Freely available for re-use

Bookstore.DTD

XML Schema definition(XSD):

• Includes full capabilities provided by DTD
• Is Namespace'able
• Since the document is based upon xml standards, the normal xml parse is used to parse the xsd document.
• Can define data types, elements, attributes, nestings, orderings, etc; and what the data can/cannot contain.
• Easily extendable
• Since its based upon XML, I believe its easily learnable.
• Contains builtin data types
• XML document has an XML Namespace to refer to and an XML DTD to define it. This becomes overhead when a parser examines the document, it may have to link this all in, interpret the DTD for the schema, load the namespace, and validate the schema; all before it can parse the actual XML document; this overhead may seriously degrade performance or system availability.

Bookstore.XSD



If you like to look more, the Document Structure Description(DSD) defines the next generation schema languages, see examples.

Related Posts

Popular Posts