
Hello PubNub and Pusher users – we now speak your language. Welcome to Ably - matt_oriordan
http://www.ably.io/adapters
======
sean_patel
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.

~~~
matt_oriordan
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-
pa...](https://blog.ably.io/rails-5-actioncable-the-good-and-bad-
parts-1b56c3b31404).

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-...](https://blog.ably.io/routing-around-single-point-of-failure-dns-
issues-7c20a8757903#.oqciqec1t) 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...](https://blog.ably.io/the-18-ghosts-in-your-
infrastructure-stack-that-can-cause-failure-and-how-to-avoid-
them-1373daebfe1a#.b7ya3o94o) 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
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
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](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...](https://blog.ably.io/the-story-of-how-ably-came-to-
be-1d859f2c9a90#.cri0ppexg)

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](https://www.ably.io/compare)

~~~
sean_patel
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!

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

