At blitz.io, for a while there, we were only relying on CouchDB clusters as the primary NoSQL database with some in-memory caching. As we grow (rapidly) and scale out, there are aspects of what we collect and store that are transient and real-time. While CouchDB is awesome for the map/reduce, replication and incremental view indexes, the real-time queues (emails, counters, stats, etc) natural lend themselves to, yup, redis. We are in the process of rolling out geo-located redis instances as part of our global infrastructure.
Archive for DevOps
Dear Angry Nerds, meet Blitz the Bird Thrower
This is a repost of my Atlassian’s guest blog, announcing a Bamboo plugin for blitz.io.
The pig of a problem
We all know what happens when your app performs like a pig. You lose users, customers and revenue. Your app is slow, the failing pigs don’t amuse your customers and you hear about it as the trending topic on Twitter. In most cases you don’t even know that it’s slow until you push the app into production, multiple times a day. How can you identify performance bottlenecks earlier in the cycle? And, if you don’t discover them how to you find and fix them as fast as possible?
Enter Blitz – a performance testing tool, built by Nerds that were angry at how the existing tools weren’t keeping pace with the new Application Development Lifecycle that has Continuous Integration as its center piece.
blitz.io: Geo-located Traceroutes with Heroku, AWS and CouchDB
Okay, not the greatest, ground-breaking, coolest, earth-shattering feature ever. Let’s just get that out of the way. But, in the process of troubleshooting various latency issues for our customers, we found ourselves logging on to various EC2 instances of blitz.io to run traceroutes to our users sites/apps to diagnose problems. We are developers, hanging out in TextMate, vim and our terminals and the ability to take a local Unix command and run it remotely while staying in our zone (shell) was important. So …
Continuous Integration with blitz.io
Short blog, this one. At blitz.io we take continuous integration very seriously, in a fun sporty kinda way. In the era of polyglot programmers, we realize that all of us have our own favorites on programming languages for the specific app in mind. With the rise of PaaS and our ability to deploy apps faster than ever, we strive to bring load and performance testing to developers into the CI cycle, in your language of choice.
blitz.io: Now a Heroku add-on in private beta!
We are super excited to enter private-beta of blitz.io as an add-on in Heroku. Since the launch of blitz.io a little while ago, we are seeing tremendous adoption by app developers to quickly and easily check the performance of their cloud and mobile apps. Add utility pricing with no commitments to that mix, all of a sudden scaling out doesn’t seem all that expensive.
blitz.io: How many dynos do I need on Heroku?
Whatever PaaS offering you are using, this is a very common capacity-planning question: How many dynos/instances of my app do I really need in order to support x concurrent users at any given time. Auto-scaling and elastic-load-balancers are awesome, but you still need to know what you are up against. With the ruby gem from blitz.io, this is super easy to iterate and find out for yourself before you go live!
Easy Application Monitoring with blitz.io and Tropo
Been chatting with @chrismatthieu about getting a Tropo app going and especially with the EC2 outage, thought might be interesting to combine the Ruby Gem for blitz.io with the Tropo API to create a dead simple application monitor that I can run anywhere with any frequency.
The day DevOps became NoOps
The Internet haz gone down, at least parts of it. Last night, the Virginia EC2 region started experiencing all sorts of issues with their EBS storage (some suspect it’s the bandwidth) and we are still feeling the impact. For blitz.io (which is down, BTW), we use Heroku that runs off of the Virginia region. When we first architected blitz.io, we were afraid of regional failures and the database bottlenecks and ended up deploying an entire CouchDB cluster across multiple regions with master to master replication.
blitz.io: DevOps, NoOps and Cloud Automation
If you haven’t read the interview with @DEVOPS_BORAT on devops.com, check it out. ROFL-funny but within those hilarious interview is lots of wisdom about devops. For one, it’s this whole new movement on the cloud where a few developers are both writing the code, provisioning systems, managing and monitoring them and automating the hell out every aspect of the entire system. blitz.io is no different. In under two weeks post-launch, blitz-users have generated 10,000,000 hits against their servers, added varnish and memcached to their app, resolved various lock contentions, and continue to tweak and optimize the code, all by themselves! We do think load and performance testing should be this fun and easy!
