armon

It is actually just a difference of naming. Gauges in statsd operate the same as kv data in statsite. Originally, both projects referred to them as kv, this seems to be a more recent change in statsd.

I work at Kiip, where we write primarily in Python, Erlang and C. We have built several in-house analytics systems than can handle upwards of 300K qps. We are hiring too: http://kiip.me/jobs

I work at Kiip, and I can confirm that our "non-durable purely in-memory solution" is Redis.

I'm not saying that one solution avoids the need for setting up things in a sane way. In both cases, you need to configure things properly or you can shoot yourself in the foot.

However, depending on the systems your company uses and your configurations, one solution might be simpler than another. Network topologies tend to be very static. You might have a public subnet, and a few private subnets.

Over time, you might add or remove web servers to the public subnet, or add various services to the private subnets. Especially if you are using a Service Oriented Architecture (SOA), you might have many different services that need to interact with each other, but not with the public internet.

When you are using security groups, you need to make sure to have separate SG's for each category of machine (public, private) and then manage them at a service level, and manage the interaction between multiple SGs. For example, Web should be available on port 80 from the internet, but the DB should only be available on port XX accessible from the Web SG. But also accessible from the same port from a Service SG, etc.

So as you continue to iterate on your services and deploy new ones, you need to be constantly tweaking the security group configurations. With VPC, once you have a sane public/private topology you can forget about it.

Additionally, most SOAs try to provide some form of high availability. For us, that means cross region / cross AZ replication and availability. Doing cross AZ is fairly simple in both EC2 and VPC, but doing cross region in EC2 is a pure nightmare. You cannot apply a security policy across regions, so you have no simple way to allow your nodes to communicate.

Since VPC acts as a distinct private network, we can simply use site-to-site VPN configurations between our regions, and nodes can easily and freely communicate with each other. There is nothing to worry about, since the private subnets are connected over VPN, and are using hostnames that are only routable within our private network.

Don't get me wrong, security groups can be properly used to provide a totally secure environment where only trusted nodes are allowed to communicate. You can add monitoring and configuration testing easily as well. But once you try to scale up past a few servers, move to a SOA, and provide cross-region availability, VPC becomes the simpler alternative.

I think if you take a moment to read the context you would have a better understanding of the security issues involved. EC2 acts like one giant multi-tenant network. The only thing preventing access to your nodes is the SG policies, which are fairly trivial to mess up. The linked slides shows people running memcached in EC2 with weak SG configurations exposing their data to the public internet (this includes some very large companies).

The primary advantage of VPC is that it provides a private, single-tenant network. The advantage here is that you don't need to rely on complicated SG policies to maintain security.

Although VPC is part of the same infrastructure, the two have very dramatically different network configurations, which makes then clearly distinct. The networking environment of VPC much more closely resembles what you would have if you were using physical infrastructure. This means you have control over the routing tables, DHCP, DNS, network topology, etc. These are all things which are out of your control on EC2.