_bpo

nginx+lua can be exceptionally fast. It's the basis for OpenResty, which is a consistent top-performer in the Web Framework Benchmarks (http://www.techempower.com/benchmarks/)

Webdis is a neat project, but I'd be a bit wary of deploying a custom HTTP server written just for Redis interactions. Nginx is battle-hardened.

If the database provider hosts databases within the same data center that your app is in, ping times are no different than they would be if you ran your own DB in that data center.

Products like RedisGreen host their servers within Amazon and Google's data centers, and are meant for customers hosting their apps within those data centers. In the case of RedisGreen, you choose your hosting provider, region, etc, when provisioning resources.

If you sent database queries across the open Internet, ping latency is just one of several problems you'd encounter.

(disclosure: I work for RedisGreen)

anyone interested in this, would you mind emailing bpo at redisgreen.net ?

I absolutely acknowledge that inter-region AWS usage is over the open Internet, and no one's encouraging bad habits like transferring unencrypted data between regions here.

VPNs are great. AWS security groups are reliable too.

Hi, I helped build this. A few notes about security since people are asking...

RedisMonitor supports AWS security groups for people who are interested (just hit support and ask after signing up). This is the safest way to open up Redis for the security-conscious.

Standard security on a Redis server is a very long password checked at login (AUTH). All of the communication between client and server is unencrypted. We consider this reasonably safe within EC2, high risk over the open Internet.

Redis doesn't have TLS. A few clients have forks with TLS support, but we haven't audited their security at all yet and (frankly) we don't trust them at all.

Hi there,

I'd love to help you. We (RedisGreen) run extremely high-performance, dedicated Redis installations and work directly with customers to help tune their app and their installation for the best possible service.

Getting Redis up and running is easy, as has been mentioned in this thread. But the devil is in the details. Third-party vendors distinguish themselves in terms of active monitoring, quality/knowledge of support, and closed-source features (e.g. one company offers what they call "multicore Redis").

I've been running large-scale production instances of Redis since 2009, and our other team members are similarly qualified.

I'd love to help you out and give you honest recommendations on system scaling. bpo at stovepipestudios.com

As a representative from one of the competitors mentioned there, I can tell you that feature list is dishonest and absurd.

When someone offers you "infinite scale", run.

I work for RedisGreen - a different take as we do dedicated servers and focus on analytics/monitoring. Feel free to ping me with any questions. bpo at stovepipestudios.com

"Immutable Server" seems like an oxymoron.

Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on).

The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server.

Seems like your organization has just coined a new synonym for "gold master"

Computer systems in the wild are stochastic - that's the fundamental assumption that leads to the design of tools that you call "PFCTs" here.

This type of design leads to tooling which is relatively slow and often obtuse, but there are well-reasoned (and researched, start maybe with [1]) assumptions behind those tools. In particular: systems modeled by these tools are designed to run for years, include a large variety of hardware and software, to be worked on by a lot of different people, and to be able to grow to massive size.

The "clean slate" idea is a good one, and has been in use for a long time (the idea of gold images goes way, way back). But that's for initial system state, not dynamic system modeling. The cfengine family of tools grew out of limitations in the "clean slate" approach for real-world system models.

If your concern is "how can I deploy my Rails site to EC2 quickly and reliably," you'll have different goals and assumptions on the tools you need, than if your concern is "how can I grow a resilient infrastructure". (edited to add: both are completely legitimate goals)

All that aside, I definitely agree that the tools still suck :)

[1] http://cfengine.com/markburgess/papers/sysadmtheory3.pdf

The target key was published on 5/20.

    # gpg --list-packets /tmp/snowden.asc
    :pubkey enc packet: version 3, algo 1, keyid 5B50940B79DEBE35
        data: [4096 bits]
    :encrypted data packet:
        length: unknown
        mdc_method: 2
    gpg: encrypted with 4096-bit RSA key, ID 79DEBE35, created 2013-05-20
      "Verax (Informed Democracy Front)"

(79DEBE35 can be found on the subkeys.pgp.net keyserver)

Digital Ocean has more on their status site: http://digitaloceanstatus.com/

This would be somewhat easier to swallow without the picture of the boat.