Thanks a lot for these replies and the follow-up questions :)
I wrote this post more as a starting point for discussion than a sales pitch. Developing everything would have been quite long.
That's a lot of questions, I will try to answer them all.
- I understand your point about the cloud. I agree that it's easy to take any web service and put the "cloud" sticker on it. Let's just say that we built the hosting platform and we provide it as a service running on an infrastructure itself available as a service. That’s as cloud as it gets.
We are currently in the first stages of our development. We have the service working, used by developers without much network & server management skills. They are very satisfied, but the platform & tools are clearly not in the state we are targeting.
The platform is currently in beta, we don't offer strong SLA. I understand very well that it can be a real issue, but we’ve had very few outages since starting the beta (less than 8 hours in the last 12 months of beta), and we really can't ward our users against outage from our own service providers (currently Azure). However, we monitor issues & outages and communicate about them and about the resolution process. We currently offer support contracts on a case by case basis.
From a security point of view, we have put in place several security layers on our side to ensure isolation of application containers. We don't handle data storage yet because we want to be sure we can do that while enforcing a good enough security level. So right now we don't store your data. (But developers may well use databases like SQL Azure, tables or clearDB mySQL offering from the same datacenters)
For better isolation & performance (and direct client-server communication) it's possible to deploy dedicated instances currently on request and in a few months from the management portal. For even more security, it could even be possible to deploy a Stormancer cluster on your own infrastructure, whether cloud based or not.
We provide some security through SSL for websocket and HTTP. All API calls are secured through a symmetric key system (we may switch to JWT before the end of the beta) and monitored.
Legal protection is a tough subject. We have it for everywhere around the world... except the US & Canada. For now.
We provide an SDK which abstracts a lot of things like object serialization, communication channels (through a route system), room load balancing & lifecycle management (we call them scenes). Our SDK also offers open source multi platform client libraries (not enough platform now, we are building new libraries on request however),
The server SDK is written in C#, and designed for non blocking logic The customization pattern is behavior based.
We currently provide only a few turnkey behaviors on top of this framework, it's clearly something we want to work on. We are going to open source them on github too. We are doing that only a step at a time, mostly to take the time to clean things up. For instance, if you need something as simple as a realtime push or broadcasting server, you can do that without coding anything at all on the server. But you can also customize these components with your logic (and your code!), or create something from scratch.
For instance, we are also working on a matchmaking module, and another which will handle the base features of turn based games. We also make sure (when possible) that these turnkey components can be used together.
The available tools are:
- An open source command line system. Currently only works on Windows, we need to add some alternative authentication logic on the platform to port it on Linux. If needed, just ask.
- A local emulator (windows only too. Same as the command line, Mono support is on the roadmap, could be moved up on request). Manageable from the cmd line, and as soon as we get the time from an included web application.
- The management portal. Should go open source too, as soon as we get time to do some code cleaning.
- Management libraries for .NET, PHP & javascript
- Server library currently distributed through nuget.
- Client libraries currently for .NET, Unity, javascript and soon C++.
Network
Currently, it's websocket, so TCP (SSL) only. I agree that it requires a lot of tweaking to get the most out of it, and that's really not adequate for fast paced games. But on the good side it works almost everywhere, even behind transparent proxies for mobile games.)
Good news, Raknet integration is on the way: It will bring UDP and unreliable messaging to the platform.
What did you mean when you wrote websocket only was a deal breaker? Do you need unreliable messaging (UDP) or HTTP web hosting?
HTTP web API hosting is something that some developers asked us, so it's on the roadmap, but with a low priority because it's rather easy to integrate Stormancer into an existing web application hosted elsewhere.
Right now, it's possible to build custom, authenticated HTTP APIs (curl compatible) for Stormancer server apps. This enables full control of the Stormancer app from your own web servers for instance, without having to deal with bidirectional communication.
Deployment
Deployment is done through the command line (> stormancer deploy). Ultimately it's only an HTTP PUT request, so developers could very well build other tools on top of it, or integrate it into custom deployment workflows. We keep the 10 last deployments (configurable on request) and it's possible to rollback to any of them in the management app. Deploying a new version doesn't disconnect players by default, as different game versions can live side by side. However new connections happen only on the newest deployment.
We might add support for different environments in the future (ie production, staging...). However the feature can be replicated by creating 2 apps.
Monitoring
Monitoring is currently possible through a persistent logging system, and we should roll out a metrics system before the end of July. We are clearly not satisfied by the situation here so we are working on it. Our monitoring stack runs logstash & Elastic Search. I would be happy to get the opinion of people experienced with this subject about this stack.
We don’t do turnkey A/B testing right now, as we are focusing on the hosting/networking part. However, it should be possible to implement that through parametrized scene creation, custom metrics and some game client logic. Not trivial, but not overly complicated neither.
Building something better could be definitely feasible, however I would need to think more about use cases for realtime, synchronous apps A/B testing.
Samples and benchmarks
We have a few samples in Unity, javascript and native C#. For instance we made a very simple multiplayer version of Angry bots (explained I a two-part tutorial: part 1 and part 2), and a quizz game in C#. You can find more samples and tutorials on our blog.
We are working on a full quizz benchmark app (requested by a customer) including Database connections and with simulated players.
Apart from the free plan, Stormancer will be available as Pay as you use.
Developers will be able to buy compute units of different sizes with a base cost of 20€/month (300MB RAM, 1 CPU share) .This is not set in stone however, we want to adjust that with the data from our benchmarks and feedback.
