You could hack around this by creating two auto-scaling groups with different instance types and then have them follow the same metric such that the small group goes to 0 and the larger one spins up. Not a great solution but better than nothing.
Jelastic can run docker in two separate ways:
1) the way when the image is running as a plain VZ container (advantage: many extra features become available, disadvantage: compatibility with native docker is not 100%)
2) run via Native docker engine, but instead of VM (like everyone does) elastic VZ container is used as a host machine for running embedded containers. Compatibility with classical docker is 100% + vertical scaling as an extra feature, because of VZ layer on top.
Basically both ways of running docker images allows to have flexible and managed resource management so vertical scaling is indeed available for both of them.
BTW, Kubernetes in Jelastic is using the same approach that makes Jelastic only available platform for K8S on the market with "pay as you use" billing model, where you can pay only for consumed resources and not for the limits as everyone does.
Hi, Jelastic founder is here. Thank you for mentioning our product. Vertical scaling is not a marketing :), it's reality.
Jelastic public cloud providers offer automatic vertical scaling with pay-as-you-use billing model (please do not confuse with pay-as-you-go). Except this our team helps related technologies to become more elastic, for example Java https://jelastic.com/blog/elastic-jvm-vertical-scaling/
Regarding the docker support, there are two flavors inside Jelastic:
1) Native Docker Engine - you can create a dedicated container engine for your project in the same way as you do on any IaaS today, for example “How to run Docker Swarm” https://jelastic.com/blog/docker-swarm-auto-clustering-and-s.... An advantage here is the vertical scaling feature. In Jelastic unused resources will not be considered as paid while at any other cloud provider you will have to pay for the VM resource limits.
2) Enhanced System Containers based on Dockerfile - there is no need to provision a dedicated docker engine or swarm. This solution provides even better density, elasticity, multi-tenancy and security, more advanced integration with UI and PaaS features set compared to #1. It supports multiple processes inside a single container, you can get an SSH access and use all standard tools for app deployment, write to local filesystem, use multicast and so on. It supports traditional or legacy apps while images can be prepared in the same familiar Dockefile format. Unfortunately it's not fully compatible with Native Docker Engine due to specifics limitations/requirements of docker technology itself.
Thank you for pointing out this issue. In the upcoming release we will clarify the difference between two and provide more tips which one is better to use in various cases.