waxzce

It was just to be clear that we do not have a financial involvements together

Other project meaning being contributor to open source together?

:-)

Very simple: you need to get higher level of service, instead of paying for servers you need to pay for up-time. It's what PaaS, managed service or serverless does : manage server for you, at scale. To have something online you need: - servers - VM/OS management - Scalability system - monitoring (hardware, OS, applicative & functional) - action on monitoring and escalation management - update every weeks - observability

That's what we provide at Clever Cloud BTW https://www.clever-cloud.com/

Can I ask which alternative are cheaper?

Yes, exactly like years ago we do not have full applications but use application servers to run our apps. At this time it seems to be a good idea. And now we advocate 12 factors, for good reasons

We heavily use Haproxy at Clever Cloud

scala is functional, swift is not

so swift is more like groovy or something like this...

clever cloud

:-)

In fact it's exactly why we create FS bucket in the Clever Cloud product : http://doc.clever-cloud.com/databases-and-services/fs-bucket...

ok, we will do it

* Over how much time are the load metrics computed? For how long do they have to go above 85% to trigger a scale?

=> all metrics are computed in the more appropriate interval for each, and we improve this continuously. Main metrics are computed each 15 seconds today. We take the up scaling decision quickly, and we downscale less quickly, but this is very reactive.

* Do you compute the average load across all scalers? Or some percentile?

=> Across scaler and only one, we try to avoid false positive by an infinite loop ;-) (and it works) I never remind a customer unhappy of this feature.

* Can these parameters be tuned ? Can the load and the scaling decisions be seen (a part from the bill?)

=> you can manage how many you want to spent, it's important. But you can discuss with support to tune all of this.

* Assuming other bottlenecks (like IO), you won't notice high CPU or RAM load, but you would notice a spike in response time. Do you allow, or have any plans, to include other metrics in the scaler or to allow customers to export custom metrics?

=> Many metrics are watch, I/O included. And we will add an API to get metrics in the future

* Do you allow to spawn long running background processes. If yes, how does it interact with the CPU load based scaling?

=> Yes you can do it

* Can the user add placement constraints when deploying an app in multiple DCs ? Can the scalers themselves span multiple DCs in the same region. If not do you plan offering access to configuring loadbalancers to serve traffic to multiple app instances serving as a single logical app?

=> Yep, all of this is in the task list for future region.