** As per usual - this is just me thinking aloud, and is not intended in any way to represent my employer's position **
I used to be fairly sure what my job description was, but as time marches and things change, the clarity crumbles... Safe to say, I'm a software guy... My current role is at a large NZ insurance company helping them implement a system on salesforce.com, which as you are probably aware is one of the world's leading Software as a Service (SaaS) providers. Like most systems, the core product is good for 80% of the time, but won't cover the other 20% and we must close the gap (between what you need, and what the product provides) using a combination of techniques: customisation, configuration, and (where the result is still not close enough), writing code.
But as a solution provider, how should you allow your partners/customers to place their own code into your code-base? Salesforce.com have exposed a complete development 'layer', which allows us (the developers) to create html pages in a mark-up language called Viusualforce, and to control the behaviour of those pages by linking them to code written in a language called Apex, which is a OO java-like syntax. The whole development platform is hosted in the cloud... changes to the the code files get pushed up, and if they don't compile, they won't save... everything's hosted, hence 'Development as a Service'
I have been working with DaaS for 10 months now, and I am aching - longing - yearning - for writing code on my PC again... Writing code in the cloud can be monumentally frustrating, especially when one is constained by NZ's notoriously poor infrastructure.
I was recently asked my someone 'what about offering a hosted platform - is there a need for it?', and whilst I completely failed to answer the question, I did have the following thoughts:
From a customer's perspective, here's what's really great about consuming SaaS, or more specifically *Solutions* as a Service:
- When the underlying OS/db server needs patching (Microsoft, Oracle, Linux, whatever) then I (the consumer) do not need to worry about implementing the patch or regression testing the base solution.
- I do not need to purchase hardware or software (boxes, OS, database servers, etc).
- therefore, I do not need to hire professional expertise to manage the hardware/software/system.
- The software is already implemented and being served. All I need is a login and I'm away. I'll still need to apply config changes, but I'd need to do those on top of a local system implementation anyway...
And here's a few of the reasons why you just shouldn't bother:
- I (still the consumer) do not have control over my own servers. If the service provider rolls out a patch, then I *have* to regression test my customisations and implement any fixes as are needed, whether I currently have the capacity to manage this or not (I might be tight up against a project deadline, and do not have spare resource just to make sure that was working last week is still working). If I choose not to take the patch, then I run the risk of drifting into the dreaded 'unsupported' territory...
- I will need to ensure I have thumping quick internet from my ISP, which may be additional (hidden) costs, and
- I will need to ensure I have good proxy servers that can route the traffic quickly and robustly. Typically, companies have proxy servers that deal with people browsing for bits of this or that to do their job, and maybe looking at the Herald/TradeMe during lunch... now, they will have (n) users hammering the internet getting their data up and down the wire all day every day. Again, this could well mean expensive upgrades and extra costs...
- The two points mentioned above (the ISP and the proxy servers have become additional points of failure in the uptime of my system, not to mention the actual application servers (the physical boxes located over in San Francisco* for Salesforce.com). There is no evidence to suggest that hosting solutions on internal servers has greater uptime than those hosted in the cloud, incidentally, but I can tell you from experience that it is *substantially* more annoying when they go down and it wasn't your fault, and there's nothing you can do to fix it...
* Production salesforce.com servers are located in Asia for the Asia-Pacific (and hence NZ) market, but we still need to push our code all the way to San Fran and back to hit the development servers (or 'sandboxes', as they are quaintly named)...
- You may or may not have thoughts on the security of storing your data in servers located overseas. Often, companies keep their (confidential, sensitive) data in servers that are physically located in locked server rooms...
The bottom line, as far as I can see, is that it's important for SaaS providers to understand what is so awful for an average company about running applications on servers... and then remove that pain:
The provision of cloud-based services is a good basic premise, as long as the provider can offer a more compelling option for them to browse to an application using just the web browser of their choice than it would be for them to create, host, distribute and support their own LOB applications; By more compelling, I mean:
- Better quality software / solutions
- Smaller overall TCO (Total Cost of Ownership), remembering that the boxes themselves are just about cheap as chips these days.
There are always pros and cons to any system, of course. But consumers need to carefully ensure that one outweighs the other before jumping on the SaaS bandwagon.
From what I can see, Development as a Service still has far too many cons to outweigh the pros...
