Ahh good point. Be worth sending the dc onsite guys some goodies at xmas to keep them on side in case they decide to move away without telling you.
So the guys at @Bromcom-PR told me about this thread about my SoSaaS definition (among other things) and they challenged me to sharpen up the definition as requested by GREED below.
matt40k's notion of grey and white clouds - yes there are definitely both types.
The problem with the grey versions of cloud and SaaS is that people have taken existing client-server software and just put them in the cloud but they haven't adapted them for it. You may call it SaaS - "software you use you do not manage" per GREED - but it's only SoSaaS, not true/white cloud according to the widely accepted NIST definition (which the UK government uses to define its 'Cloud First' policy).
The nub of the NIST definition is that cloud is a "shared pool" of dynamically allocated resources. If you don't change the software to behave like this internally then you may be putting it on top of a cloud, but it doesn't become cloud software unless you change it on the inside as well.
Does that work as a definition or do I need to expand on it do you think?
Interoperability is a huge benefit of SaaS. Third party software developers can manage MIS integration from their end, rather than having to support software on some school computer that's subject to constant environmental changes.
As someone that has integrated software with a number of cloud-based MIS solutions, I can say that it took me less time to write that integration than I spend solving SIMS integration problems every week, and it never fails.
There are difficulties associated with SaaS, but it's such a common software model now that all of these have been addressed long ago. You have to be security conscious with any application that deals with this kind of data. In my experience, you're actually improving security by moving in-house to cloud-based, as the software vendor can apply it's vigorously tested security to all customers alike, removing a lot of the potential for client-side security lapses.
I've read this thread with interest, and obviously I'm speaking from the point of view of a software supplier rather than consumer, but I think that many people are overloading the basic Software as a Service definiton with a lot of additional concepts (all of them progressive) but which doesn't really get delivered by SaaS. For instance the Gartner definition of SaaS (Gartner IT Glossary - Software as a Service (SaaS)) says "software that is owned, delivered and managed remotely by one or more providers". It doesn't incorporate any concepts of elasticity, cost, integration or technology. It doesn't even have to be run remotely - just delivered and managed remotely.
The definition crucially talks about how a customer pays for the service delivered by software; which seems to be an important move away from "owning software in perpetuity" to "paying to use a service delivered via software". As an extreme example Adobe delivers its Photoshop application on-demand with updates remotely managed and delivered, on a subscription basis. This qualifies under the Gartner definition as a SaaS model of delivery. Its not browser based or "integrated" any further than the "perpetually owned" version, so I guess this would be your "SosaaS" example.
The NIST definition defines the Cloud Software as a Service in similar terms "The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure" - how the provider provides elasticity (or even whether it does so efficiently) isn't a consideration. The NIST does say "Note: Cloud software takes full advantage of the cloud paradigm by being service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability." but doesn't define why the "Cloud Paradigm" delivers any of this within its own definition of Cloud - I suspect what they wanted to say was "HTML REST" rather than Cloud. I'm guessing that everyone here's expectation of a cloud delivered MIS would be HTML + REST (which would be a sensible assumption).
I would be very interested in the groups weighted shopping list of capabilities above and beyond "remotely managed and delivered, and subscription based payment" that would attract you to a "true cloud" application rather than, say, a Browser Terminal Services hosted existing MIS (which fulfills the definition of SaaS) ?
The US National Institute of Standards and Technology‟s (NIST) definition of cloud computing is the most widely adopted one, and has been adopted for G-Cloud; it states that:
“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or cloud provider interaction.”
This cloud model promotes availability and iscomposed of five essential characteristics (On-demand self-service, Broadnetwork access, Resource pooling, Rapid elasticity, Measured Service); threeservice models (Cloud Software as a Service (SaaS), Cloud Platform as a Service(PaaS), Cloud Infrastructure as a Service (IaaS)); and, four deployment models(Private cloud, Community cloud, Public cloud, Hybrid cloud). Key enablingtechnologies include: (1) fast wide-area networks, (2) powerful, inexpensiveserver computers, and (3) high-performance virtualization for commodity hardware.
SaaS is part of cloud definition and hence SaaS application needs to meet NIST definition of cloud. As to key the subject matter in this thread, Cloud, SaaS vs SoSaaS - client-server applications when hosted as SoSaaS, fail to meet cloud definition in its severe shortcoming in characteristics to share executable code and RAM working storage; client-server application behave as originally designed in an environment that (a workstation) where such resource sharing would have never been needed to be considered. This non-resource-sharing characteristic curtails scalability of such application. Therefore client-server application is not viable as a commercial proposition for scaling beyond minimal to moderate size users against native web-application. The comparison RAM storage requirement is up to 50-fold more for client-server application compare to same application written as web application. You need to add also the extra cooling, electricity supply and of course rack space needed!
Last edited by Bromcom-PR; 24th February 2014 at 08:12 PM.
I think you make the point very well; given all the information you provide from the UK Government Cloud paper, the UK G-Cloud still allows the provision of SosaaS to be presented for rental to government customers. I recognise that SosaS is nowhere near as efficient (if centrally hosted - not just centrally managed and provisioned) than an equivalent zero-state application design, but this measurement of efficiency would be evident to potential customers because it would be reflected in the service charge to the customer - inefficient centrally hosted applications will be more expensive to rent than efficient centrally hosted ones. The G-Cloud does not insist however that any application is centrally hosted; just centrally and efficiently provisioned, and available at a published price.
So; apart from the cost benefits (gained by efficient application design) that are expected to be delivered by a SaaS solution, whats the group's weighted shopping list of features (interoperability has been mentioned by mikecampbell, but presumably there are others such as device independence etc) that are not strictly anything to do with SaaS but are expected to be delivered via a SaaS application ? What does SaaS mean to the community other than the raw "centrally provisioned, and not perpetually owned" definition ?
If you ask G-Cloud Team, they will confirm readily that any cloud/SaaS offering that relies on application software that falls outside NIST defintion of cloud will be be allowed on G-Cloud.
G-Cloud Team confirmed that client-server applications fall outside NIST cloud definition and will not be allowed on G-Cloud store. If you have any different formal information please share with us.
You and your facts Matt!
The comparison RAM storage requirement is up to 50-fold more for client-server application is not from stats. They are results of tests. You can repeat reasonable easily if you want to check as follows:
Simulate any client-server based MIS application (or any other application for that matter) running in hosted environment. Measure the memory is being been taken each time you sign in via client application as an extra user or even open a new session for the same user. You will see that client exe will capture 250 MByte RAM for the exe code and working RAM storage. This is because the exe behaves just as it would have behaved in workstation/PC in a local network connected to the server - client exe is not aware of multi-tenancy demands in cloud and hasn't been designed for the exe code to be shared - ie in computing terms it is non re-entrant. Hence failing to meet NIST cloud definition at fundamental level in sharing resource.
If you repeat the same tests with a web-based application, you will find that because code is shared (re-entrant), each user takes only 5 MByte RAM and this is for extra users own working storage area. Web backend and client has been designed from outset as a resource to be shared - meeting NIST cloud definition. That is why you can massively scale up and host thousands/millions of users with web applications economically.
I hope the above helps.
Last edited by Bromcom-PR; 25th February 2014 at 12:26 PM. Reason: Formatting quote
Sims Intouch - Have you signed up?
I always thought he was a system architect or someone quite high up in the dev team, as the help with technical sims error messages has been right on the nail.
Loving this discussion by the way.
Out of interest, would people consider SLG SAAS or close to it? Since it was written to be held centrally and should respond better, quicker etc. I don't mean in terms of it being scalable on-demand, paid for by unit etc. just in terms of the difference between client-server model to cloud based. Or is it too simplistic to just consider browser based access as being more cloudy? I feel that quite often people want browser based, and they think of that as cloud, but is that necessary fulfilling the definitions...
We've met before - I presented at the EduGeek Conference with my colleague a few years ago on the subject of the movement to "industrial computing" clouds. My post is Chief Architect at Capita SIMS. I'm interested in this thread because the definition of SaaS is slippery and despite some formally proposed definitions, it definitely means different things to different people; for some it means "cheap, reliable software that I dont own" (the minimalist point of view) all they way to very specific technologies; I need to make sure I am keeping up with the communities aspirations in this regard, not just what the formal definitions are stating.
As an example; would the community be satisified that a "app" delivered solution which stored its data in the Cloud but was locally installed (like all iOS Apps) was a valid SaaS application, or does the local install invalidate it, irrespective of the cost-free nature of the installation ? Where do people perceive the highest value of an SaaS application to be - purely financial (i.e. its cheaper than an on-premises solution) or is there a need for it to conform to some other principals (and if so, what is that need being driven from) ?
GREED (25th February 2014)
Sorry if I'm being picking but until some independant person\company publishes a report showing their findings quoting numbers like 250MB of RAM vs 5MB of RAM is total rubbish. I've just opened SIMS and done a few things and it's sitting at 24,316KB, I'm sure if I allocate more RAM it'll eat it, or if I spent the entire day in SIMS it'll grow but it's still a way off from your 256,000KB you've quoted.
Like I said, I'm not arguing that optimized vs non-optimized won't help, I completely agree, sticking something like SIMS .net in the cloud would be silly when you compare it to something like your MIS that has been designed for the cloud from the ground up. I'm just saying stick to the actual hard facts. You're not having to waste resources running multiple copies of the OS for example. Rather than quoting unscientific numbers, it doesn't help. They get quoted as fact then business cases fall part at the first huddle because the facts aren't actual facts.
There are currently 1 users browsing this thread. (0 members and 1 guests)