Skip to content

Instantly share code, notes, and snippets.

@somic
Created July 22, 2010 15:50
Show Gist options
  • Save somic/486149 to your computer and use it in GitHub Desktop.
Save somic/486149 to your computer and use it in GitHub Desktop.
The lock-in I believe @randybias is referring to (and I personally
totally agree with him on this) is more subtle.
There most likely are not going to be significant issues moving a system
consisting of 1 or 2 instances.
But imagine you have a 10-instance topology in GoGrid. GG has 2 NICs, but even
more importantly - one NIC is private network (which gives
you access to your storage), the second NIC is public (instance's public
IP address is directly attached to it). It's not unreasonable to assume that
each server's quota on the former is bigger than on the latter.
The biggest issue - how do you know that this topology when it ends up
on EC2 will also need to run 10 instances, even if you matched CPU statedpower? In EC2 your private and public
traffic are on a single NIC. So you need to consider if that single NIC
will support all your traffic needs. Also, while CPU and memory allotments
per instance are always clearly explained, network bandwidth guarantees
or clear explanation of allotments are not always clear (this makes
apples-to-apples comparison of networking resources quite not trivial).
Additionally, GG hosts are persistable by default, in EC2 it's done
using EBS which also uses (underneath, not visible to your instance) the
same NIC. So it's even more traffic to worry about and plan about.
Deciding which app listens on which NIC is something you don't even
bother on EC2, but you do need to do it in GG. Sec groups are in EC2,
but in GG you don't need to worry about it. Local firewall (iptables)
will be significantly different on 1-NIC vs 2-NIC system.
This list goes on and on. The more complex a topology gets, the more
extreme networking and storage peculiarities become: factors
like speed of access to storage, bandwidth, how much bandwidth gets eaten by access to storage, how much private vs public bandwidth,what runs where to make sure it can access storage at adequate speeds,
what needs to run where to meet HA and redundancy requirements, etc
are going to play role so big that it's effectively a lock-in. None of these
affect images or convertability of images.
All in all, it's rarely about
apps runnings on 1 or 2 instances, it's about bigger apps (10+ instances)
or interconnected multiple apps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment