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

21–30 of 35 posts

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

#21

Post by automatthew »

djb_hackernews wrote: post #19
automatthew wrote: post #17

Earlier quoted context omitted.

Regarding the architectural question: We actually tested a few designs using m2 and 0mq during our R&D phase. 0mq's push/pull sockets provide the same "take" behavior as the Redis RPUSH/BLPOP, so we definitely could have used m2 as the HTTP end of a similar architecture to what we use now. One of the considerations that led to the choice of Redis was the transparency of the queueing and dequeueing. The messages in th…

Nice post. Do you do anything special to make the queue which your workers are BLPOPing durable? Is there a reason you didn't use Redis pub/sub? Seems like the perfect use case.

The "queue" is merely a Redis list. Durable by default.

Redis PUB/SUB is not suited for the task queues we use, because any number of subscribers will receive the messages. We want to guarantee that only one worker will act upon each message.

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

#23

Post by lolcatstevens »

sdepablos wrote: post #20
lolcatstevens wrote: post #18

Earlier quoted context omitted.

We've been bitten by EC2 instances having issues accepting incoming connections (multiple HAProxy boxes in TCP mode to an STunnel cluster), and we've never had that issue in testing with ELB. ELB also beats our failover time when we lose an EC2 machine. But ELB is in no way a permanent part of our infrastructure (nothing is permanent) especially as we move to supporting technologies such as SPDY on spire.io or, for e…

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 AWS a few times in the past and had some magic (at the time ciphers and removing SSL v2) done to our ELBs.

We have seen issues with performance on ELB which is why we originally went with TCP mode HAProxy on the edge of our stack to a cluster of STunnel servers, but again reliability was an issue here and our ELB performance with up to 10K rps looks great in benchmarks. Past 10K we are considering separate dispatchers behind a separate ELB. But at that point I am also tempted to, frankly, switch to our own metal.

Curious: are you comparing ELB performance vs High I/O EC2 instances (say m1.xlarge) open to the world?

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

#24

Post by automatthew »

rwolf wrote: post #5

I like the apologetics for node.js in the first section. a similar argument for why you are using jruby instead of node.js for the "backend whatchamajigs" would be nice.

The short answer is: Use of synchronous Redis calls made it easier to develop and to experiment with storage patterns.

Workers can be written in any language, which was another major design consideration. We have about a dozen types of worker right now; when we want to evaluate a new language, we can port just one. Alternatively, we can write any new worker types in an arbitrary language.

Thus we're not married to JRuby.

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

#25

Post by reinhardt »

stefanve wrote: post #22

Maybe a bit off topic, 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.

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.

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

#26

Post by djb_hackernews »

automatthew wrote: post #21
djb_hackernews wrote: post #19

Earlier quoted context omitted.

Nice post. Do you do anything special to make the queue which your workers are BLPOPing durable? Is there a reason you didn't use Redis pub/sub? Seems like the perfect use case.

The "queue" is merely a Redis list. Durable by default. Redis PUB/SUB is not suited for the task queues we use, because any number of subscribers will receive the messages. We want to guarantee that only one worker will act upon each message.

Err, I guess I meant something else. For instance, what happens if one of the workers goes down after popping? The message is lost, right?

I think I invented your architecture in my head that isn't near reality. I imagined you were using the workers to take incoming published messages and pushing them into the queues that subscribed connections are popping off of. Effectively building your own fanout. So in this context, I was wondering why not just use pubsub which will handle fanout and get rid of the entire worker model.

Thanks for the reply!

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

#27

Post by spladow »

stefanve wrote: post #22

Maybe a bit off topic, 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.

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.

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

#28

Post by kozubik »

reinhardt wrote: post #25
stefanve wrote: post #22

Maybe a bit off topic, 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.

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

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

#29

Post by keithnoizu »

reinhardt wrote: post #25
stefanve wrote: post #22

Maybe a bit off topic, 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.

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.

Service as a service.

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

#30

Post by nl »

stefanve wrote: post #22

Maybe a bit off topic, 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.

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

Post reply on HN