Monthly Archives: July 2012

July 4, 2012 · 1:44 am

Macbook Pro Retina migration

This could become a lengthy post but perhaps quite informative. Let me start by saying that I have been running a series of MacBooks for probably 10 years and slowly migrating from on machine to the next means that an enormous amount of useful tools have accumulated, but also an enormous amount of general “os plaque”. So with this one, I’m starting clean. I’ll move stuff across piece by piece, file by file, and in the process hopefully do some amazingly productive spring cleaning.

  1. Well, basically I started using the machine, and very early on installed Google Chrome Canary to take advantage of retina goodness.
  2. Next, solarized terminal colours.
  3. Installed Quicksilver
  4. installed skype
  5. ran software update and restarted
  6. installed git for snow leopard version.
  7. I tried to avoid Fink (because it required a compiler installation on anything later than 10.5)
  8. tried to install Bashmarks, realised I needed command line tools for mac
  9. Installed mac ports
  10. downloaded and installed command line tools for mac
  11. Installed java developer tools for mac
  12. Installed pip, virtualenv, virtualenvwrapper following this post
  13. Installed eclipse juno classic.
  14. Installed pydev for eclipse
  15. Copied ~/.ssh from old computer
  16. Moved pieces of ~/.profile from old computer to ~/.bash_profile on new
  17. Installed heroku toolbelt and moved credentials from old machine in ~/.heroku
  18. Starting moving itunes library using home sharing
  19. Regretted starting afresh rather than using migration assistant
  20. Installed AWS tools
  21. Installed s3cmd
  22. Moved various credentials files from .ec2, .s3cfg etc
  23. Installed omnifocus
  24. Installed Airfoil
  25. Installed Spotify
  26. Installed ScanSnap manager etc. You suck at software fujitsu, seriously?
  27. Installed google drive.
  28. Decided that google drive storage sux. Dropbox is so much more expensive though, what to do??
  29. Started working on setting up virtual env and getting eclipse to work, checked out some git repos and watched 4 Corners.
  30. Got up in the morning, iTunes import completed (~120GB), imported playlists. (btw, seriously apple, how many times do I have to enter my appleId???)
  31. Setup eclipse for high-resolution. Read this, it works. You need to both change Info.plist and then copy the app, and restart.

There is still much to do, particularly regarding moving docs across, but I feel cleaner, lighter, and overall warm and fuzzy from the spring clean.

1 Comment

Filed under development, technology

Tagged as , ,

July 2, 2012 · 8:37 am

Plan, architect and test for failure in the cloud

With 2 recent outages in AWS‘s east region, I believe it’s worth writing a post about the oft-touted tenet of architecting for failure. If you’re using AWS, your application should be built and tested* for an entire AWS availability zone failure as was the case in the most recent 2 failures in the US East AWS region. Providers like Heroku should really be providing this sort of resilience. My site which runs on Heroku went down (shock horror being such a precious web service and all!) with both these outages and I’ve been talking to the Heroku team about this shortcoming. I’ll post back here when I have a better understanding of their fault tolerance strategies.

While amazon are regularly espousing the “architect for failure”, few companies fully understand how to do it, and even fewer actually test such an event. Certainly part of the blame has to lie with AWS for failing to test their redundant power supply setups, especially given the same problem has happened twice in as many weeks, but nonetheless, this is the reason they always build more at least two AZs in any one region, and in the case of US-EAST-1, four AZs!

Cloud advantage specializes in fault tolerant cloud architectures, but one of the missing pieces is a clear test strategy for new AWS users. Simon Elisha, principal solution architect for AWS here in Australia provides are great introductory presentation on this sort of thinking. Whilst with the latest failure in AWS, Netflix admit some amount of disruption of service to customers, their architecture is also renowned to be extremely resilient to failure. Their team was so focussed on designing for failure, they invented chaos monkey to simulate a variety of different failure events, and more specifically gorilla monkey to simulate an entire AZ failure.

The truth is that the cloud will be the future for tech infrastructure, but a paradigm (please excuse the use of that word) change is required in application development. A good place to start is with AWS’s whitepaper itself.

Despite what is said by customers and the like regarding this latest disruption, I’m very interested to here what comes from the AWS team’s postmortem on root cause.  When an event like this happens to a provider as big as AWS, I believe the actual downtimes for various web sites and the like is less than initially stated in the media. Secondly, it would be good to see as thorough postmortem from properties like Instagram and Netflix about why their services failed to failover to other availability zones sooner.

If you’re reading this blog, I’d love the chance to chat to your firm about how to build a robust cloud infrastructure since I believe with the right design, almost always a better result than your current infrastructure is achievable.

Update:

Finally an AWS postmortem: http://aws.amazon.com/message/67457/

Leave a Comment

Filed under amazon web services, development, technology

Tagged as , ,