Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

spire.io

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#31

Post by nl »

kozubik wrote: post #28
reinhardt wrote: post #25

Earlier quoted context omitted.

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 don't understand the business model at all. 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 ove…

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)

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#32

Post by kozubik »

nl wrote: post #31
kozubik wrote: post #28

Earlier quoted context omitted.

I don't understand the business model at all. 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 ove…

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 t…

Ok, fair enough. I'm still wrapping my head around JSAI (javascript as infrastructure) so bear with me ...

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#33

Post by tbatterii »

kozubik wrote: post #28
reinhardt wrote: post #25

Earlier quoted context omitted.

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 don't understand the business model at all. 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 ove…

"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.

pubnub is supposedly servicing 100K messages per second now. And I would guess it's not just chat.(http://techcrunch.com/2012/03/21/as-developers-seek-more-int...)

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#34

Post by gyaresu »

spladow wrote: post #8
gyaresu wrote: post #4

Your chat demo is broken. http://www.spire.io/examples/chat/

I know this is the least satisfying support answer possible, but the chat appears to be available for me right now. I'd like to help figure out the problem, can you give me some details like your OS and browser?

Opera Version: 11.62 Build: 1347 Platform: Mac OS X System: 10.7.3

https://www.dropbox.com/s/nhqolr7q11vb4hj/Screen%20Shot%2020...

Re: Behind a Backend-as-a-Service Provider: The How and Why of Our Architecture.

#35

Post by sdepablos »

lolcatstevens wrote: post #23
sdepablos wrote: post #20

Earlier quoted context omitted.

Haven't you run into performance terminating SSL on ELB? For me the performance is so-so, as I'm using a 2048 bit key and it seems I hit the maximum requests per second limit pretty fast. There're a pair of threads regarding this issue on the AWS forums, where a user did a really exhaustive test of ELB and even got an Amazon engineer to really look into that issue: https://forums.aws.amazon.com/thread.jspa?messageID=…

We're looking pretty good in AWS West 1a. The second thread you linked shows great performance from markdcorner's second load balancer -- the https://forums.aws.amazon.com/servlet/JiveServlet/download/3... image -- vs the original ELB, which SpencerD@AWS describes as a custom ELB with some sort of customer-requested secret sauce (maybe some sort of "slow start" to some backend servers?). Indeed we have reached out to…

Well, I didn't know you could fine tune your ELB's. In fact reading the Developer Guide (http://awsdocs.s3.amazonaws.com/ElasticLoadBalancing/latest/..., page 46) it seems that it's now possible to choose SSL protocols and ciphers via the web interface (and I supposse also via the API).

Regarding the comparison you suggest, we are too short-handed right know not only to do this kind of comparisons but even to think to manage our own load balancers ;) Thanks for the suggestion anyway.

Post reply on HN