How is this different from Signal R? Signal R provides Real-time Duplex communication. It's dead-simple to use and it's FREE. https://github.com/SignalR/SignalR
I looked at ably.io's features / platform page https://www.ably.io/platform and don't see anything that Signal R can't do.
Can someone from ably.io convince me as to why I should be shelling out 500$ a month (as an enterprise client) to use ably.io? The only reason I see is an existing technology stack that can't allow or handle Signal R (.Net) and that's a weak argument.
Apples and oranges. Ably is a cloud service. It costs money, but so does SignalR if you factor in having to run your own servers (and not just the servers themselves but also the ongoing operational labor. $500 is nothing in that context).
I say this as an operator of a competing cloud service, defending the product category. ;)
I never understood the need for pub/sub as-a-service.
Running your own pub/sub service is easy - As easy as running an HTTP service - Scaling out is also almost as easy as scaling an HTTP service. Yet no company is offering HTTP-as-a-service; that would be silly.
I think that the whole industry exists because of a myth spread by PR and marketing. We'll see in a few years. I think people will come to their senses eventually.
Yep, creating a barebones pub/sub service is pretty trivial (and fun!).
But then you may find yourself slowly adding things that a decent pub/sub service should have. E.g. connection state recovery, so that a client on a phone driving through a tunnel gets all their messages (in the right order) once they reconnect. Presence, and presence data. Stored history. A permissions system. Encryption. Smart push notifications. Decent multi-region federation, so a channel that happens to only have subscribers in ap-southeast doesn't roundtrip messages to us-east. Guaranteed message ordering preservation. And so on.
And eventually, you end up spending what adds up to quite a lot of effort, which could have been spent in ways other than slowly recreating the SAAS.
I think that's the case for a lot of SAAS products (that creating a barebones version of the product yourself is pretty trivial, but the SAAS is still a useful product, since often people don't just want a barebones version).
There are a quite a few open source pub/sub solutions which handle connection state recovery, authentication, encryption, in-order-and-exactly-once delivery, auto-scalability (on Kubertetes or Swarm)... And they give you even more flexibility than what you can get from a third-party service (which give you limited or no ability to customize back-end logic).
There might be a few minor features which the third-party service might have which the open source solution doesn't have; but you can always extend the open source solution to have those features; this not the case with the third-party service; in that case you're stuck with whatever features are being offered by the service...
For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution.
I would say that the argument for using third-party pub/sub services is the opposite of the one you made; it's good for simple projects which have limited requirements, but not good for larger companies with more advanced requirements.
Thanks for the well-thought-out response, I appreciate it. Of course you're right that for some usecases, rolling your own infrastructure on Kubertetes or Swarm with an open source solution rather than using a SAAS is the right way to go. (But then, the same thing is true of most SAAS products). BTW, I'd be interested to know if you had a particular open source product in mind in your first para?
> For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution.
I'd query a few of these -
- Re channel name length: we have no particular limit on that...?
- Re lightweight protocols: The article we're commenting on is actually about us adding support for more protocols :) (including MQTT, which is pretty lightweight - though that one's not in general availability yet). We also support queues as an alternate way to consume data, which gives you AMQP and STOMP too.
- Re batching: Clients can batch messages together into a single protocol messages as they like, just by passing an array of messages to publish(), and subscribers will receive them all together. (Which assumes they're all for the same channel, but if not, not sure what it'd mean to batch them).
- Re analysing data streams on the backend as they arrive: you can subscribe to messages on your server, and then do what you like with them. (Or alternatively use our queueing feature, which lets you have arbitrarily many independent backend workers consuming messages from the queues). It is true that you can't filter messages before they're broadcast to other clients, though. I guess our answer to that would be to have the client publish to a channel that only the server has permissions to subscribe to, set then have server filter those and rebroadcast on a different channel. (Probably in combination with the queues, so you can have multiple server workers doing this). It's true that that will add a bit more latency, though.
- Re advanced authorization rules -- our token capabilities system allows the server pretty fine-grained control over the permissions it grants each client.[0] But sure, it's never going to be as flexible as a completely custom solution.
I've not done an in-depth review yet, but from what I can tell SignalR has the following shortfalls:
- It relies on a single message bus for message passing between nodes. If your rate of messages exceeds what the bus can handle, you're in trouble.
- I don't believe it handles connection state recovery as a service, and certainly does not do that across moving connections i.e. a disconnected client may arrive an another server yet messages may have been published whilst disconnected.
- SignalR does not support multi-regions, once again due to the central bus, so if you have users in Asia and your datacenter in US, they'll all have to route everything through US.
To be quite honest though, we're now rarely having discussions about technology X versus Ably, because Ably is realtime platform-as-a-service, and not a software solution. To provide the scale, reach, resilience and feature set we have, it can only be achieved with a combination of infrastructure and software. So our customers are choosing us because we're investing a lot of time and effort in all aspects of the service, not just the realtime software itself. See https://blog.ably.io/routing-around-single-point-of-failure-... for details on how the Dyn attack did not affect us for example, or https://blog.ably.io/the-18-ghosts-in-your-infrastructure-st... for some details on we've built necessary resilience into every aspect of the system.
I plan on doing an in-depth SignalR review soon in fact, thanks for the prod.
Thank you Matt! I see your value proposition now. MaaS as a SaaS (i.e. Messaging as a Service as a Software as a Service) :)
I still think that the strongest use case would be for large enterprises ( think Uber) that would be spread across geographical locations and would need something like this - reliable, with state saved and spread across data-centers.
For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year).
Hi - Matt's tied up atm, but I'll try and reply. (I'm also at Ably).
> For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year)
I'm afraid I don't follow that. We have a generous free tier (a lot of startups are fine just on that), and self service packages starting at $20/month. And very cheap overage pricing - $1.25 per million messages + $12.50 per 1000 peak concurrent connections, so people who aren't sure how much they're going to use (often the case with startups) can just pay what they use. I've linked to it elsewhere in the thread, but: see https://www.ably.io/pricing/self-service.
I think you reached that number from the cost of the 'enterprise' package, but that's really for companies whose corporate policy requires that they have a personal account manager they can call at any time or something, or who want customised versions of things (eg versions of client libs with our name replaced by theirs connecting to a CNAME on their domain). Not really relevant for young startups.
> did you see that there was a 'problem' in the space and built an MVP, or did you create this need?
We weren't the first company in the space -- e.g. Pusher and Pubnub were both here before us -- but we weren't happy with the existing solutions for a bunch of reasons, see https://www.ably.io/compare
Ok, I get it now. It looks like your Team has put a lot of thought into the Pricing model, and now the way you have explained it, everything makes sense.
Also, this quote from the blog post rings true.
> The barriers to entry are truly immense due to the incredibly complexity, brainpower and investment we have made in our product.
Thank you and I wish you the best with your startup!
Did you guys have a client for who you built this for, and then branched out into a SaaS / startup, or did you just build it and then tried to get clients later? i.e. did you see that there was a 'problem' in the space and built an MVP, or did you create this need?
(I work at Ably) Others have already replied to the main question, but just on this - the enterprise package is only if you want the features that come with that package, it's not like we try and detect what kind of business you are and charge you extra based on that. Free tier gives you 3 million messages/month, and above that we've transparent, usage-based pricing - https://www.ably.io/pricing/self-service
14 comments
[ 3.3 ms ] story [ 40.1 ms ] threadI looked at ably.io's features / platform page https://www.ably.io/platform and don't see anything that Signal R can't do.
Can someone from ably.io convince me as to why I should be shelling out 500$ a month (as an enterprise client) to use ably.io? The only reason I see is an existing technology stack that can't allow or handle Signal R (.Net) and that's a weak argument.
I say this as an operator of a competing cloud service, defending the product category. ;)
I think that the whole industry exists because of a myth spread by PR and marketing. We'll see in a few years. I think people will come to their senses eventually.
Yep, creating a barebones pub/sub service is pretty trivial (and fun!).
But then you may find yourself slowly adding things that a decent pub/sub service should have. E.g. connection state recovery, so that a client on a phone driving through a tunnel gets all their messages (in the right order) once they reconnect. Presence, and presence data. Stored history. A permissions system. Encryption. Smart push notifications. Decent multi-region federation, so a channel that happens to only have subscribers in ap-southeast doesn't roundtrip messages to us-east. Guaranteed message ordering preservation. And so on.
And eventually, you end up spending what adds up to quite a lot of effort, which could have been spent in ways other than slowly recreating the SAAS.
I think that's the case for a lot of SAAS products (that creating a barebones version of the product yourself is pretty trivial, but the SAAS is still a useful product, since often people don't just want a barebones version).
(Disclaimer: I work at Ably)
There might be a few minor features which the third-party service might have which the open source solution doesn't have; but you can always extend the open source solution to have those features; this not the case with the third-party service; in that case you're stuck with whatever features are being offered by the service...
For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution.
I would say that the argument for using third-party pub/sub services is the opposite of the one you made; it's good for simple projects which have limited requirements, but not good for larger companies with more advanced requirements.
> For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution.
I'd query a few of these -
- Re channel name length: we have no particular limit on that...?
- Re lightweight protocols: The article we're commenting on is actually about us adding support for more protocols :) (including MQTT, which is pretty lightweight - though that one's not in general availability yet). We also support queues as an alternate way to consume data, which gives you AMQP and STOMP too.
- Re batching: Clients can batch messages together into a single protocol messages as they like, just by passing an array of messages to publish(), and subscribers will receive them all together. (Which assumes they're all for the same channel, but if not, not sure what it'd mean to batch them).
- Re analysing data streams on the backend as they arrive: you can subscribe to messages on your server, and then do what you like with them. (Or alternatively use our queueing feature, which lets you have arbitrarily many independent backend workers consuming messages from the queues). It is true that you can't filter messages before they're broadcast to other clients, though. I guess our answer to that would be to have the client publish to a channel that only the server has permissions to subscribe to, set then have server filter those and rebroadcast on a different channel. (Probably in combination with the queues, so you can have multiple server workers doing this). It's true that that will add a bit more latency, though.
- Re advanced authorization rules -- our token capabilities system allows the server pretty fine-grained control over the permissions it grants each client.[0] But sure, it's never going to be as flexible as a completely custom solution.
[0] https://www.ably.io/documentation/general/authentication
I've not done an in-depth review yet, but from what I can tell SignalR has the following shortfalls:
- It relies on a single message bus for message passing between nodes. If your rate of messages exceeds what the bus can handle, you're in trouble.
- I don't believe it handles connection state recovery as a service, and certainly does not do that across moving connections i.e. a disconnected client may arrive an another server yet messages may have been published whilst disconnected.
- SignalR does not support multi-regions, once again due to the central bus, so if you have users in Asia and your datacenter in US, they'll all have to route everything through US.
To be quite honest though, we're now rarely having discussions about technology X versus Ably, because Ably is realtime platform-as-a-service, and not a software solution. To provide the scale, reach, resilience and feature set we have, it can only be achieved with a combination of infrastructure and software. So our customers are choosing us because we're investing a lot of time and effort in all aspects of the service, not just the realtime software itself. See https://blog.ably.io/routing-around-single-point-of-failure-... for details on how the Dyn attack did not affect us for example, or https://blog.ably.io/the-18-ghosts-in-your-infrastructure-st... for some details on we've built necessary resilience into every aspect of the system.
I plan on doing an in-depth SignalR review soon in fact, thanks for the prod.
I still think that the strongest use case would be for large enterprises ( think Uber) that would be spread across geographical locations and would need something like this - reliable, with state saved and spread across data-centers.
For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year).
> For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year)
I'm afraid I don't follow that. We have a generous free tier (a lot of startups are fine just on that), and self service packages starting at $20/month. And very cheap overage pricing - $1.25 per million messages + $12.50 per 1000 peak concurrent connections, so people who aren't sure how much they're going to use (often the case with startups) can just pay what they use. I've linked to it elsewhere in the thread, but: see https://www.ably.io/pricing/self-service.
I think you reached that number from the cost of the 'enterprise' package, but that's really for companies whose corporate policy requires that they have a personal account manager they can call at any time or something, or who want customised versions of things (eg versions of client libs with our name replaced by theirs connecting to a CNAME on their domain). Not really relevant for young startups.
> did you see that there was a 'problem' in the space and built an MVP, or did you create this need?
Re how we came to be, Matt has a blog post on that - https://blog.ably.io/the-story-of-how-ably-came-to-be-1d859f...
We weren't the first company in the space -- e.g. Pusher and Pubnub were both here before us -- but we weren't happy with the existing solutions for a bunch of reasons, see https://www.ably.io/compare
Also, this quote from the blog post rings true.
> The barriers to entry are truly immense due to the incredibly complexity, brainpower and investment we have made in our product.
Thank you and I wish you the best with your startup!
Did you guys have a client for who you built this for, and then branched out into a SaaS / startup, or did you just build it and then tried to get clients later? i.e. did you see that there was a 'problem' in the space and built an MVP, or did you create this need?
Thank you! ~Sean
(I work at Ably) Others have already replied to the main question, but just on this - the enterprise package is only if you want the features that come with that package, it's not like we try and detect what kind of business you are and charge you extra based on that. Free tier gives you 3 million messages/month, and above that we've transparent, usage-based pricing - https://www.ably.io/pricing/self-service