I totally misread this and, after a glance, thought that it was a nice cross-language RPC library. Like many fiddly bits, whipping up a quick protocol is simple (and I've built one that I like), but I'd be happier to use one that everyone is helping build/maintain/document...
But I was wrong... This is a service... or something. The web page suggests library, but the pricing page suggests service. Color me confused.
[An aside: these Pusher, PubSub, whatever businesses exhibit very little in the way of barriers-to-entry. As the price to replicate the service falls (as smart folks think "pay for that? I just make it into a gem/pip/AMI!" and crush the implementation costs), I'm curious how these business will survive. See Engine Yard...]
The Flotype Bridge Cloud service is intended to be a free/cheap way for you to try, learn, and use Bridge.
Think of it like Joyent's No.de service, which is a free way to host Node.js apps.
The technology is actually targeted at larger-scale applications, and enterprise sales is the focus of our business model. We've had some great traction on the enterprise front, but we're not ready to announce that yet.
We're not in the business of nickel and diming fellow developers each month.
At first sight, this seems awesome. I've been looking for something like this for a while. However, The homepage seems to be a little sparse in terms of specifics. Before implementing this as a core part of a product, I'd like to know:
- Pricing model?
- Seems free for now, but how about when it's out of beta? How are you going to ensure you stay alive without making me go out of business?
- How does this work? "Magic scalability" is mentioned, which sets a red flag for me. We process >1B requests a month (and growing), and we've found that even the best tools have to be used carefully. Black box software such as this is very scary.
- How is this deployed? Is it on EC2, which would mean low latency between our infrastructure and the bridge servers? Is there an installable version for people who aren't on EC2? Seems to be a requirement, since message / queues and internal apis require low latency to process things quickly. Especially if we're basing our entire internal service-oriented architecture on top of it.
I want to love this, but there's a lot of unanswered questions, at least from perusing this site. I've learnt the hard way to not believe in magic.
When it's out of beta, there will be a free tier on Flotype Bridge Public Cloud, and a few paid tiers for people that would like us to manage the Bridge server. This is meant for smaller applications.
We can handle 1-2 billion messages/day on a single 8-core server. "Magic scalability" refers to the concept of Bridge Services[1]. If you write code to publish a Bridge Service, you can magically scale by simply firing up more instances of that code. You'll read more about this in the docs.
This can be deployed anywhere - EC2, Rackspace, or your private datacenter/cloud, whatever! We just need to make kernel/OS level optimizations for each stack. The Flotype Bridge Cloud runs on EC2, but you can buy and run Bridge anywhere you want.
Yes, there is an installable version. The goal of Bridge is to build a messaging system for products with very large messaging needs (billions of messages/hour or more). (This is just a beta). For such applications, subsystem latency is crucial, so the primary deployment model is for you to install it next to your application servers.
Please email me at darshan @ flotype.com if you have any more questions :)
It wasn't really clear to me what the advantages of this is over a ZMQ+Socket.io based system. The aim is a fully-baked SAAS I suppose, but it seems we already have all the pieces to roll our own without too much effort.
ZMQ is for server-server on the backend. Socket.io would be client-server for the frontend. But the pieces in the middle would have to translate between ZMQ semantics and Socket.io semantics and it's all ugly. There is no way for a ZMQ endpoint to directly address a Socket.io client, and always have to go through this complex intermediary component.
As I point out in the video, this is the strategy today. Hook up a bunch of different pieces together.
Bridge is meant to be a solution that provides the same semantics for server-server and server-client communication.
from a design standpoint, the points are a bit distracting..and to me (not as important as the titles in most cases). I'd rather see the titles aligned to the left as HN currently displays. I think points can be equally important as comments as well as aligned to the right. otherwise, nice work
hmm, probably I dont't understand it that well then. assume that a client sends an async request to a server, but server being down, busy whatever, doesn't respond, a client should be in a position to set a timeout, and take so
e action e.g try another server or something. no ?
But I was wrong... This is a service... or something. The web page suggests library, but the pricing page suggests service. Color me confused.
[An aside: these Pusher, PubSub, whatever businesses exhibit very little in the way of barriers-to-entry. As the price to replicate the service falls (as smart folks think "pay for that? I just make it into a gem/pip/AMI!" and crush the implementation costs), I'm curious how these business will survive. See Engine Yard...]