elijahchancey's comments

elijahchancey | 7 years ago | on: We Don’t Run Cron Jobs (2016)

It’s worth noting that SQS promises “at least once” delivery. In practice, this means some messages will be delivered multiple times.

After every job is successfully finished, it should be noted in your db. Every time a worker starts processing a job, it should check the db to see if this job has already been run.

elijahchancey | 12 years ago | on: Ask HN: Freelancer? Seeking freelancer? (April 2014)

I read on a recent Hacker News thread that you're looking for a new client. I'm an Infrastructure Engineer who is also looking for a new client in SF. I was wondering if you knew of any companies that could leverage my expertise on a part-time basis. Please let me know if you can think of anyone. My experience is detailed at www.elijahchancey.com.

I'll keep my eyes open for opportunities that suit you. Thanks for your time!

elijahchancey | 12 years ago | on: Ask HN: Freelancer? Seeking freelancer? (March 2014)

SEEKING WORK - devops - san francisco or remote

i live in san francisco and most recently was the lead devops engineer at bleacher report, the 3rd largest sports website and the 36th most trafficked website in the states. i am a consulting (systems administrator | systems engineer | devops engineer | site reliability engineer) and am currently looking for a new client.

here's a brief description of the work i did at bleacher report, which is the 3rd largest sports website and the 34th most trafficked website in the us. i reduced costs by migrating from engineyard to aws. i built completely new infrastructure and increased scalability & reliability by using autoscaling. i succeeded in halving monthly infrastructure costs from ~$150k to ~$80k and refactored chef cookbooks for all stacks. managed traffic surges of key sports events that surpassed 2,000 requests per second.

more information is available at www.elijahchancey.com

elijahchancey | 13 years ago | on: Ask HN: Best setups to avoid availability outages on AWS

Assuming we want to minimize latency and maximize reliability, we want to create a stack that:

1) Has AutoScaling Groups & Elastic Load Balancers in two regions (and only two availability zones; let's keep front-end instances in the same AZ as your local/region-specific DB)

2) Has Databases in two regions and uses Master Master replication

3) Instances talk to their local DB. If they detect their local DB is down, they failover to the remote DB (ie, the far region). If they failover, they notify you.

4) DNS does geographic load balancing (pre-ELB). You'll need to use a provider like DynDNS or UltraDNS to give you Geo Load Balancing & Failover. Or, you could pair a monitoring service like CatchPoint with Route53

5) Application caching (Memcache, Redis, etc). Let's not put more load on the DB's than necessary.

That's a good start, at least.

page 1