There Is No Cloud

I wake up at 5:30 AM to lift weights and run. That's my own personal sanctuary from what is now my work day. My work day consists presently of helping a company manage applications and data "on the cloud". I do not think about "the cloud" while I'm working out... typically.

Late last week while doing cardio, I start listening to one of my subscribed podcasts as I always do when engaging in such a miserable activity for the benefit of my heart. The podcast of choice on that morning was TWiT. This particular episode came directly on the heels of the big Sidekick data loss fiasco - which just happened to be the loss of a ton of customer data such as address books, text messages, and other fun bits of personal data that was stored... guess where? That's right - "on the cloud". The TWiT crowd on that particular episode had a fun time with that term for the opening ten minutes this story was talked about. Thankfully neither Dvorak or Laporte were actually there, or else it may have just been intolerable. Regardless, they had a fun time talking about how "the cloud" failed.

Actually, no - that data was stored somewhere in the bowels of Danger's and/or Microsoft's infrastructure. Their infrastructure, and their policies/procedures around it are what failed. "The cloud" didn't fail anyone here.

Why? Because there is no cloud.

The "cloud" is just an abstract term that we used to use when drawing diagrams of networking infrastructure or system architecture. The "cloud" is drawn to represent parts of the diagram we either don't control at all, or don't care enough about how they work to include them in our documentation, or both. Normally this refers to things outside of our network, or just the internet in general.

This is what drives me nuts about the usage of the term "cloud" in the media. In their view, anything that lives outside of a user or company's machines or on-site storage is "on the cloud", implying that the user or company has no control of it or doesn't care how it works - which is bogus. Everyone I know who is doing something with a so called "cloud provider", be it AmazonAWS or Google AppEngine (notice there is no "cloud" in those titles) knows how those services operate, how their data is being managed on it, incorporates the internal workings of the service in to their architectures, and have plans in place to make sure they aren't totally wed to storing that data and applications on those services with some semblance of disaster recover in place were something to go horribly wrong.

Viewing those services as "a cloud" is just dead wrong. When dealing with my clients with work on Amazon EC2, I'm very careful not to refer to anything as "the cloud" to them. It's either "servers/elasticIPs,volumes on ec2" or "storage on s3". I want my clients to understand specifically that the services we are dealing with are services that we should own the process for using and understand how it works. The services are not an abstraction. They are real. In fact, I'd argue that this whole "cloud" movement changes nothing other than

1. The interfaces for how we deal with storage and application hosting are now remotely programatically accessible - this is a good thing. Essentially traditional system administrators are being replaced with APIs, which is great revenge given their previous collective views of everyone else in the world.
2. The previously mentioned storage and hosting is now distributed. By now we should all know that making things distributed is better for us all.

What I'd like to see happen is for anyone who talks about the "cloud" actually refer to those platforms by what they really are. Call "the cloud" for your Apple stuff MobileMe and describe it in the terms used for MobileMe. Describe your applications living on ec2 and your messages living in Amazon SQS. Stop using the blanket term "cloud". There is no cloud.

Staying Focused on a Mac

I admit it... I have mild ADD. Luckily there are a couple of apps on the Mac that help me focus on a single application at a time, despite the fact I might need to keep several applications alive at any given time.

1. Isolator - This one was suggested to me by my friends over at Mystic Coders. This nifty application works in the same way that predecessors like Doodim do. It basically leaves the application in focus at the current screen brightness but dims or completely darkens the rest of the screen. This is ultra useful if you want to keep any eye on windows (e.g. irc) but you don't want them to dominate your attention while you toil away in another app.
2. Witch - Witch basically provides alt+tab behavior that works kind of like it does on Windows. For what it's worth its worth, I find the cmd+tab behavior between Apps only to be less of a cluster than sifting through all open windows I might have on a Windows machine at any one point. However, Apple's default cmd+tab behavior is lacking if you need to do something like very quickly giving focus to a minimized window. This action typically require you to pick up the mouse or perform multiple keystrokes. Witch reduces this burden by allowing you to use alt+tab like behavior to give focus to or un-minimize any individual window. This helps me stay focused by allowing me to minimize windows of applications that I don't need active and getting them back quickly without needing to touch my mouse.
   

Firefox DNS Cache Expiration

Every need to increase the frequency in which Firefox invalidates DNS cache? At my current shop, we use separate DNS servers to draw the lines between parallel environment (e.g. QA and Pre-Production). Switching back and forth between the environments is as easy as modifying my /etc/resolve.conf file. However, Firefox actually caches those hostname mappings retrieved from DNS rather infrequently by default and I'd find myself quickly killing and restarting the Firefox process just to have my browser keep up at the frantic pace I was switching between environments. To expedite this, Firefox has a setting, available at about:config that allows you to modify how often Firefox invalidates its DNS cache.

The preference is Network.dnsCacheExpiration and its value is an Integer that represents the number of seconds to wait before invalidating cache.

I personally set this to 10 seconds to make Firefox somewhat instantly retrieve new IP mappings for the hostnames I was resolving. Conversely, if you wanted to speed up your browsing, you could simply set this value to something like 3600 (one hour in seconds) so you are only ever hitting DNS once an hour.