I can see how this might seem like just another way to stand out, but I think in this case BaaS really is more descriptive than the other options. Platform-as-a-Service is a broad term that could reasonably contain what we do, in that we provide a platform from which to build applications. However, the idea of a PaaS is generally accompanied by the understanding that it involves deployment solutions and is more centered on providing the network, servers, etc. What we, and other companies using the BaaS title do, has much more to do with trying to provide backend and not just a platform to deploy your own stack to. It's a matter of focus, and while the title does help differentiate us from other services, I think it does so in an honest and helpful way.
They're not the first and they won't be the last; just search for '"as a service" -software -platform -infrastructure -saas -iaas -paas' and weep (or laugh). The "as a service" meme is begging to be parodied if it hasn't been done already.
I undertand the attraction of implementing web based "messaging" (chat) in javascript. But why wouldn't I just point that javascript back to myself ?
Why would I route the product of JS based chat through a third party when it could just communicate with the server it got the HTTP from in the first place ?
My guess is that this is for folks that don't have any control over their back end - it's just a web serving black box, and this is just some more content to paste into it. Is that about right ?
The missing piece, though, is the revenue model - the users who would generate more than 30 million messages in a month are the same users who actually might have their own back end, and the wherewithal to use it. I would think if you need to use third party javascript snippets, you're ipso facto a smaller, lower volume user ...
"Why would I route the product of JS based chat through a third party when it could just communicate with the server it got the HTTP from in the first place ?"
I'll take a stab at it with an anecdote.
First it can be used for more than chat. Anything where a message bus would meet the need could work on top of this.
The project I work on uses pubnub(http://www.pubnub.com/) instead of appengine's channel api because we wanted a reliable way to broadcast to several listeners.
Where at the time the channel api would only do point to point(still does), and if you wanted broadcast you had to maintain connection state with all listeners somehow. So you would have to invent your own keep-alive protocol(not my cup of tea) etc...
So now , when the server needs to notify all listening clients of something, a json message is put in a scheduled task queue, and the call goes out to pubnub in a few ms and arrives to clients a few ms after that. It's pretty impressive.
Looks like spire.io provides similar services. essentially a cloud based message bus that supports broadcast/fan out.
The missing piece, though, is the revenue model - the users who would generate more than 30 million messages in a month are the same users who actually might have their own back end, and the wherewithal to use it
This is true, but if you had a service with the potential to generate say 50 million messages per month would you spend $60/month and use this, or multiple thousand dollars to develop your own?
(Also, note that a big market for this is mobile, not just javascript on websites)
It's not really a PaaS, because it only provides a single service (in this case realtime messaging).
That doesn't mean this model doesn't make a lot of sense.
If you are using IaaS then it can be a lot quicker to use something like this than build it yourself. Same for things like Search, or (sometimes) Database services or distribution (think CDNs).
Even if you are using a PaaS it might still make sense to use this (depending on what your PaaS supplies).
but is it just me or is the BaaS term just a marketing ploy, or at least unnecessary?
I think every thing is placable in the IaaS, PaaS and SaaS model.