Before choosing a particular vendor, we suggest you to review the list of most frequently faced limitations of some of the generally used service providers. These restrictions can affect Jelastic deployment and platform functionality.
- Public IP addresses availability
- Some service providers bind IPs to a specific node, making it necessary to re-attach IP address to different node upon container migration (A1), whilst this option is not available at Jelastic at the moment.
Also, some service providers do not support attaching more than 1 public IP addresses to a single VM instance.
Some service providers do not support attaching public IP addresses directly to node instance (A2).
- Private IP addresses
Some service providers, while supporting dedicated isolated private networks, bind specific private networks to distinct nodes. This result in the necessity to re-attach IP address to different node upon container migration (B1), whilst this option is not available at Jelastic at the moment.
Some service providers do not support attaching more than 1 private IP address to a single VM instance, making it necessary to build L2 overlay network (B2).
- Native Kernel VM acceleration
Servers with implementation of resources under hypervisors have no KVM acceleration, which is of great use for VM acceleration (C1).
- Limitation of network transfer protocols
- Some service providers do not support protocols other than ICMP/UDP/TCP/ESP (D1).
|Azure||Packet.net||OnApp||Profit Bricks||Google Cloud||Amazon AWS||OVH||Softlayer|
 - public IPs on OVH should be added to vRack
 - no kdump support for Xen-based VMs