It took a lot of planning, prototyping, testing and trial runs, but we’ve finally completed our migration over to amazon/aws.
What does this mean for you? It means significantly lower chances of down-time (our systems are waaaaay more fault-tolerant now), plus tighter security (we were always secure, but now even more so).
On our end we get to breathe easier knowing that our systems are fully redundant and scalable to meet demand, and we can start deploying new updates with confidence.
The rest of this post is a bit inside baseball, but I thought I’d share some details as we get asked about our setup quite often in support-land and at tech meetups.
About a year ago we began bumping up against walls that impeded our ability to move forward. These fell in to three broad categories: scalability, agility, and (as a result) marketing. Arguably these are good problems for a company to have (well, maybe not the marketing part), and while we had theoretical solutions for everything, the practical matter of implementation took quite a bit of time, a lot of learning and a few leaps of faith.
On the infrastructure front, our production architecture at Linode, while hyper-optimized (running arch+nginx), did not lend itself to easy scalability. Given a team of sysadmins we could have overcome this, but we’re app developers at heart. Enter aws: eb, ec2, rds, ses, s3 and route53 to save the day. While we still have a few things to tweak, we couldn’t be happier with the move. Major props to the boys at TriNimbus for giving us a hand.
On the agility front, our inability to efficiently work on isolated feature development was killing us. Branching-and-merging is not an area where svn excels. We’re now git across the board and cannot believe we waited so long to switch. We still use beanstalk for our repo origins because, well, they’re awesome. On another note, we made the mistake, in hindsight, of outsourcing some of our mobile app development. We were running low on internal man-power (as our time was getting sucked into putting out fires), but in the end having a portion of our development outsourced really killed our iterative release cycles. As we were unable to synchronously release feature updates across all platforms we got stuck in the mud. So we’re bringing development back in-house. All of it.
On the marketing front, being in a scalability bind we weren’t in a position to bring hoards of new users into the mix — though we did welcome thousands of new users through organic / word-of-mouth referrals. Now that we have the infrastructure in place to support rapid growth, we’ll be kicking things up a notch to more aggressively get the word out.
All of which is to say that it took the better part of a year to dig ourselves out of the hole we made for ourselves. Building good software and running a solid business both involve continual improvements and course-corrections, and it’s nice to be back on a path with daylight again. We’re all pretty stoked for what comes next.
We’re happy to announce that we’ve created a new forum for hanging out and discussing all things nirvana, gtd, life/work balance and more.
Think of the new forums as the local pub/cafe where Nirvana fans and the Nirvana team come to hang out and chat, exchange ideas, ponder the state of the world, discuss both deep and frivolous topics, and occasionally blow off some steam. A lot of product ideas get hatched here. Sound like fun? Come join us!
N2 Build 180 has been pushed live. This is a maintenance release to addresses a number of sync-related issues that folks have been reporting. 90% of the changes are invisible under the hood type stuff. But the 10% that you can see include:
- hovering your mouse over the sync button shows more detailed status info
- pressing shift+0 (that’s shift+zero) will bring up a gnarly looking diagnostics panel
That diagnostics panel is for troubleshooting with the dev team. It’s not a very friendly looking dialog box, but for our developers it’s like a beacon of light. It should prove invaluable for helping us figure out how to resolve issues you may be experiencing.
So, please refresh your browsers a few times until you see Build 180.
Thanks everyone, and have a great weekend.
Where is the much anticipated Nirvana upgrade we were hoping to release over the weekend? Well, ahem, our “friend” the-slow-script-alert decided to haunt our Internet Explorer power users again. We know we know, it’s our responsibility to work out the kinks, and IE accounts for less than 5 percent of our current user base, but we are expecting this number to grow and we must ensure Nirvana plays nice in the Microsoft eco-system.
Granted the alert only affects hard core users of Nirvana (you need to have entered a lot of tasks for the alert to popup) — these are the very last people we want to upset.
We couldn’t upgrade knowing that we’d be stomping on our best IE users.
So getting technical for a moment (or skip this paragraph if you don’t want to), with the user interface overhaul and added features/filters, the number of event listeners (such as click-handlers, mouseenter/leave etc) have been balooning. jQuery, which we use for ajax and DOM manipulation, is absolutely amazing — but is often used sparingly on your typical web site. Nirvana, however, is 99% DOM manipulation, and using jQuery the way most people do (and the way we have been thus far) can really start to push the boundaries of what the average browser was designed to handle. We’ve been attaching listeners to individual elements as they are rendered on screen (think checkboxes, date widgets, context menus, note detail togglers — on every task). This means that as the number of task on screen increases, so do the number of listeners (and the size/complexity of the DOM parsing). So over time with longer and longer lists, you get more and more event listeners that are constantly “listening” to every move, and it just drains your browsers resources. So, while this is the typical jQuery way of listening for events, and while it certainly is convenient for quick coding, we are taking another approach. We are now attaching ONE click event listener to the “body” element, and are determining when to do something (or not) based on what was clicked AFTER the event bubbles up. This is how many other js libraries work by default, and there’s really no reason not to do things this way with the jQuery we know and love (…except that it really is so much more convinient to simply attach listeners to DOM elements with CSS style selectors, but whatever). The boost in performance for YOU outweighs the development convenience for US. So, you win.
The upshot: we are heads-down rewriting a large chunk of the application, with the added benefit that it has sped up Nirvana performance not only for users of IE, but for other browsers as well. A huge win at the cost of a few more days of patience.
We will release just as soon as we’re convinced everything is stable.
Thanks for understanding…
Thought we’d share an interesting tidbit for those who find this sort of thing interesting…