4 ms·

Hello PubNub and Pusher users – we now speak your language. Welcome to Ably

41 points by matt_oriordan 10y ago

sean_patel 10y ago
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 https://github.com/SignalR/SignalR I looked at ably.io's features / platform page https://www.ably.io/platform 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.
- jkarneges 10y ago
  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. ;)
  - matt_oriordan 10y ago
    Thanks Justin, I obviously concur!
  - jondubois 10y ago
    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.
    - SEMW 10y ago
      > Running your own pub/sub service is easy 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)
      - jondubois 10y ago
        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.
        10y ago
- matt_oriordan 10y ago
  Hey Sean, Matt here, co-founder of Ably. I have been meaning to write a blog post on this in fact, like I did some time back for ActionCable, see https://blog.ably.io/rails-5-actioncable-the-good-and-bad-parts-1b56c3b31404 https://blog.ably.io/rails-5-actioncable-the-good-and-bad-pa.... 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-dns-issues-7c20a8757903#.oqciqec1t 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-stack-that-can-cause-failure-and-how-to-avoid-them-1373daebfe1a#.b7ya3o94o 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.
  - sean_patel 10y ago
    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).
- SEMW 10y ago
  > 500$ a month (as an enterprise client) (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 https://www.ably.io/pricing/self-service
cagataygurturk 10y ago
Your remarketing ads are so annoying. Just visited the blog post and now I am punished by seeing your ads everywhere.

41 points by matt_oriordan 10y ago

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 https://github.com/SignalR/SignalR I looked at ably.io's features / platform page https://www.ably.io/platform 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.

jkarneges 10y ago
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. ;)
- matt_oriordan 10y ago
  Thanks Justin, I obviously concur!
- jondubois 10y ago
  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.
  - SEMW 10y ago
    > Running your own pub/sub service is easy 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)
    - jondubois 10y ago
      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.
      - 10y ago
matt_oriordan 10y ago
Hey Sean, Matt here, co-founder of Ably. I have been meaning to write a blog post on this in fact, like I did some time back for ActionCable, see https://blog.ably.io/rails-5-actioncable-the-good-and-bad-parts-1b56c3b31404 https://blog.ably.io/rails-5-actioncable-the-good-and-bad-pa.... 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-dns-issues-7c20a8757903#.oqciqec1t 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-stack-that-can-cause-failure-and-how-to-avoid-them-1373daebfe1a#.b7ya3o94o 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.
- sean_patel 10y ago
  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).
SEMW 10y ago
> 500$ a month (as an enterprise client) (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 https://www.ably.io/pricing/self-service

cagataygurturk 10y ago

Your remarketing ads are so annoying. Just visited the blog post and now I am punished by seeing your ads everywhere.