I'm having a hard time wrapping my head around why someone would platform-source something as tightly coupled as client-server push services. I can see not <i>developing</i> it in house -- something like Socket.io comes to mind -- but signing up for a service to proxy communication between your app and the browser for "push" services seems a little bit on the lazy side.<p>Pushing complexity out to specialized platforms is a popular trend these days. PaaS vendors are popping up in every area, but there's a threshold where this type of outsourcing makes sense.<p>* How complex/specialized is the problem?<p>* How close is it to our core product/competencies?<p>* What are the comparative costs in development and maintenance vs using the service?<p>These are the core questions I ask when I'm evaluating PaaS vs in-house solutions.<p>Q: How complex/specialized is the problem?<p>A: Unlike HTTP, WebSockets aren't widely supported, so real-time browser communication is a complex problem. However, it is a generalized issue. It is not a problem that we will have to solve alone. There are probably libraries available to assist in the implementation of our own "push" stack.<p>Q: How close is it to our core product/competencies?<p>A: A core feature of our product is real-time exchange of pricing data between clients (browsers) and the server. The faster clients receive feedback on their pricing, the better our product works. This means real-time browser communication is central to our product. It is not core, but it is very, very close.<p>Q: What are the comparative costs in development and maintenance vs using the service?<p>A: An initial review shows that there are popular libraries that abstract a significant portion of the complexity away, including fail-over for browsers that don't have support for WebSockets. Availability of commercial support isn't clear, but source code is available. We will have to build our own API, but we have the benefit of tailoring it to our application, rather than using a generic API. Back-end message queuing services will need to be added to our monitoring suite.<p>In a more general sense, we also evaluate how the use of PaaS would affect our product in the event of downtime. Every PaaS you use in your application spreads your exposure out over their systems as well. Can you afford for "push" to go away? What will a fail-over system cost you? We opted to make real-time communications part of our app, so the redundancy we built in to our app hosting also covers our real-time services.<p>For my money, I just can't see outsourcing something like client-server "push" communication.