Traveling with US gadgets in the EU...

I'm frequently between Europe and the US--and I find some gadgets travel better than others. I travel light, but bring a few must-haves for my field.

That's a Black MacBook (aka "BlackBook"), my Vertu and an iTouch. The BlackBook is excellent for travel--when I take the energy efficient settings and keep the display lowish, I can cover a good part of worktime on a transatlantic flight with only one spare. I keep the cord on the power adapter and take two International Power adapters. One for Ireland and the UK where the power plugs are brickish with 3 square prongs--and one for Continental Europe (France, Spain, Germany, Switzerland for me) with two pin-shaped prongs. The BlackBook takes the 220V foreign power fine (doesn't need a voltage inverter), but I've noticed that batteries in the UK/Ireland take twice as long to charge.

What about connectivity? If I'm in a home, apartment or hotel, I make sure it has wireless or I stay somewhere else. I have US T-Mobile Hotspot account as well as a Germany T-Mobile account and UK T-Mobile Hotspot account. In Switzerland I buy 30-day passes on their hotspot network (the name eludes me right now). The fees vary from country-to-country with the UK's the most expensive at £40 ($80) for 30 days. That said--when you get into Heathrow from a 9 hour trip and you head downtown on the Paddington Express (which I highly recommend)--it's well worth $80 to have 15 minutes of highspeed connectivity to catch up. In Ireland I have an O2 mobile broadband subscription and in the US I have ATT mobile broadband as well as a dataplan for my phone which doubles as an EDGE blue-tooth modem. Yowza! I haven't gotten to phones yet either!

By the way--the worst connectivity I've found is in the South of Spain. We were staying with friends with no broadband. I couldn't find an Internet cafe that stayed open past my boys' bedtime. My Irish O2 broadband dongle didn't get signal. I ended up borrowing my wife's US ATT iPhone to do webmail as a last resort... likely the most inefficient web browsing I've ever done.  After my troubles I did look online and found a few outfits that rent a broadband connection (with very limited maximum usage) for a week or longer in Spain--and I'll likely try this in the future.

Phones... Hah! I started this post to share some of my transatlantic finds--and I'm realizing I have more of my own questions now than answers. That said, if you can solve this one, I'm ecstatic. Here's how I work my phones:

1. I travel with a Vertu. I bought it in a moment of weakness in the flagship Nokia store in Chicago. It's feature-free, never breaks, and always makes calls. I love it! 
2. I have a SkypeIn in the US, UK and Ireland. I give this number out. SkypeIn gives you a local number for folks to dial to reach you on Skype--but SkypeOut will then forward this call to a number you provide. Effectively shifting the International calling fees to me (at Skype rates) rather than my callers.
3. Depending on the Country I'm in, I forward this SkypeIn number to my Country-specific phone account. In the US, this is T-Mobile (I've sued them and won--and nothing positive to say about them) for lack of an effective alternative. Before I leave the US, I set my SkypeOut to the local number of the Country I'm landing in--say the UK. In London I swap my US SIM for a UK Vodafone SIM with the inbound number I set SkypeOut to forward my calls to. Note that my Vertu is a quadband, unlocked worldphone so the SIM swapping is relatively straightforward.

Now--this arrangement works great for some things. My callers make a local call, saving them International charges and hassle tracking down which country and number I'm on. I save on my calls--since I'm using a plan local to where I'm calling, I don't charge up roaming fees (which I've had at £2 or more per minutes ($4+).

And it has its drawbacks--depending on the Country I'm in and the caller's Country--I can see a noticeable delay in calls to the extent that it can cause some confusion. And often more importantly--in Europe there's a lot of texting (aka "SMS messaging") that goes on and I've found I've missed a number of texts sent to my SkypeIn number. In the end, for frequent callers, I give them both numbers and tell them to only use my local number when they know I'm in the Country.

Also--I have to keep a number of SIM cards with me in my travels, keeping track of which SIM is for which Country and which number. I also have to keep them charged--as it's not easy getting non-prepay accounts when you are a non-resident (sorry for the double negative, but that's the accurate way to put it). I've checked this arrangement with my tech buddies that travel and most of them have setup something similar to what I have now. If there's a silver-bullet that makes this trivial and I've managed to miss it, I'd love to hear what it is. Charging my Vertu? The charger takes the EU 220V without a problem and I swap the power adapter from my BlackBook as needed--the Vertu keeps two day's charge with a few hours of power.

Finally, I take with me my iTouch (iPod Touch). It carries all my audiobooks for the plane, family photos, my contacts--wifi email and in a pinch some web browsing. Really a killer device to have with me when I'm not bringing my laptop. Care of the iTouch? It charges on USB from my BlackBook--so all is well there.

Travel is a permanent part of my life and finding the right way to travel with my gadgets and staying connected is an evolving puzzle. I'd love feedback from others that have made progress and I'll continue to share my updates.

Is my MacBook faster than Google's AppEngine?

Really. I'm only a little kidding. Check it out at my AppEngine testbed. My performance.py script is available for review. Some reasons why this is the case:

1. Google is running much more on the hardware I'm using than just my process.
2. Google is using old commodity hardware. My MacBook is just faster.
3. Google quota checking is not entirely trivial and thread calls may involve heavier operations here. My MacBook using the AppEngine SDK does no quota checks.
4. New thread creation was not a performance focus for Google's platform.

Implications:

1. "You write it, we'll scale it." is a hard proposition to make. In fact, it may likely be impossible. Google has taken a very opaque approach to their platform. It is opaque because you have little control, knowledge, or understanding of how your code is being executed. Specifically--what type of server is it on? what memory footprint? what other load is on the server? what are Google-induced constraints? what are multi-server scaling induced constraints?
2. Will Google open its architecture for developer review? If not, is it worthwhile--and Google approved--to externally investigate their configuration through scripts like the trivial one I wrote?
3. Google is facing a tough problem striking a balance between keeping their unblemished record of scaling their own apps from being dragged lower by us 3rd parties. The more Google keeps to themselves about their architecture and implementation, the more risk they take on their plate. The more they are transparent, the more they put on ours. Right now we see very little--and without reverse engineering Google's platform, we can only make our findings and decide whether Google performance can be trusted to meet our needs. 

Congratulations to RightScale!

It's great to see your projects (and friends!) find success. RightScale was a venture I helped co-found with Thorsten von Eicken in its pre-seeding stages. With my hands full with RightCart and ELC, I transitioned out of the team, but we have continued to collaborate with our customers to bring disruptive technologies into play for the right problems. RightScale just closed a round of funding from Benchmark capital--a great show of support of the concept, their vision and ability to execute. The RightScale team is filled with experienced leaders and it is exciting to see their success grow. RightScale today makes Amazon's platform usable for real businesses. This is much bigger than most people outside of the EC2 tech community appreciate. Two years ago if I mentioned EC2 or cloud computing the responses were "technology is great for grid computing and research" and "not ready for web applications." And they were right! There's a whole slew of reasons for this. Some technical--no static IPs, resilient hard disk devices, etc. Some are part of the adoption cycle--need evangelists and early adopters to prove out a platform before mainstream interest. Some were brought on by the vendors in the space--SUN had a grid computing platform that was 10x the cost of Amazon's EC2 and relatively "unsexy" for the web crowd; Amazon's approach was a bit fly-by-night in its early stages--and particularly (and purposely!) lacked support and management tools. The technology concerns have by-and-large been addressed by Amazon's offering of today--and then some. The adoption cycle has had time to prove itself with early and chasm-crossing wins. And RightScale has done WONDERS in terms of providing the know-how and infrastructure to make EC2 work for grid AND web applications. All working together--I have a different set of conversations with CIO's and technology leads today. They wonder why their organizations are trying to build NOCs and POPs at huge capital expense. They wonder why a new development initiative is stalled because of a committee-eqsue email exchange over who had priority rights to the power allotment remaining in a rack at an overburden internal West Coast datacenter (that's a real one!). They wonder why development partners like ELC are able to spin up entire development and staging configurations in a matter of minutes thanks to EC2 and RightScale--while they wait and wait for IT to respond. And the final straw is cost. When you run numbers on a web deployment, leaving room for growth, bursty traffic, auxiliary servers, staging and support servers--you find that EC2 is a great value for many, many applications. So a little sleight of hand happened--early adopters braved the wilds with Amazon. RightScale heard their pains and made solutions every step of the way. First it really was large grid users that were attracted with real budgets. But many web applications today have a HUGE grid component to them--think YouTube and all that backend video transcoding (user uploads to optimal-sized web-ready flash). So the next round of EC2 interest were part web apps and part grid apps--and RightScale helped tailor solutions for them as well. Amazon heard this as well and all parties moved towards an offering that really satisfies a nice portion of the web market today. And why does RightScale make EC2 ready for real businesses? Real businesses want someone to know their problems well and already have answers for them. What happens when an instance fails? Ask RightScale! How much redundancy should I build into my configuration and how? Ask RightScale! What type of monitoring do I need and what hooks into EC2 are there to leverage an automatic recovery? Ask RightScale! Amazon wants to engage these dialogs. Especially at the tech level--they have great insightful forums--but they don't want to be hand-holding their customers and setting best practices for network configurations. Without these answers, a business can't consider EC2 ready for business--and RightScale has the right team, experience and technology to provide really good solutions. Where to next? Commoditized servers are an interesting concept. It's reasonable to think of a commodity server platform as part of a component in a product deployment. In other words--when building a product--you need some processing power. BUT, the processing power needs to be told what to do at many levels--by code, by application/database configuration, and by network configurations. So you may have these areas of concern:

1. YOUR APPLICATION CODE
1. Ex: The coding logic and schemas behind RightCart.com, YouTube.com, or others.
2. YOUR LANGUAGE OF CHOICE
1. Ex: Ruby, Python, PHP, Java
3. YOUR FRAMEWORK OF CHOICE
1. Ex: Rails / TurboGears / CakePHP / J2EE
4. GLUE TO CONFIGURE A DEPLOYMENT
1. Ex: Ant / Capistrano / Shell scripts / By Hand
5. THE SERVERS
1. Ex: RackSpace / EC2 / Your IT Dept
6. THE NETWORK
1. Ex: Cisco routing config / EC2 groups / VM virtual nets
7. MONITORING AND UPKEEP
1. Ex: Monit / External Ping / Automated failover

The next step as I see it will be to decide which of these areas are high-value and advantageous to keep under ones organizational walls and which areas are low-value and advantageous to outsource to the best provider. Making all but (1) low-value means picking a direction like Google App Engine. But then again, that today implies a language/platform choice of Python and Google's infrastructure (http library replacements, etc)--which are often tightly linked into your team efficiency, problem domain and existing code assets. Maybe it won't be a necessary choice in the future--and Google or others will support your choice of deployment language and framework (like the way we used to guard our deployment OS of choice). Amazon is heading deep into #5 and gradually adding to #6. RightScale has attacked #4, #6, and #7 where it applies to the server infrastructure. Assuming the diversity of languages exists for a positive purpose--then that still leaves a good heaping of growth before #4-7 all "just work." In other words, can we imagine a day when develop an app in a framework of our choice and then hit "deploy to application engine: Google, Amazon+RightScale, M$ft.NET, Sun.Java." As long as we are jointly solving common web paradigms, this is--in my mind--where the next step leads.

My obligatory Google AppEngine Hello World

I did my part--and gave Google's AppEngine a whirl. You can see my hello world app and maybe a bit more in the future. 

Thoughts? Total time from deciding to give it a try and having a deployed hello world app is 30 minutes. Includes minor bumbling on the concept of "application naming"--which if you are following the hello world tutorial by copy and paste--you'll want to make sure you change the line in app.yaml to reflect your application name (application: xxx) rather than hello world otherwise the application upload fails like:

google-app-engine usiegj00$ appcfg.py update helloworld/ Loaded authentication cookies from /Users/usiegj00/.appcfg_cookies Scanning files on local disk. Initiating update. 2008-05-04 14:27:15,191 ERROR appcfg.py:1072 An unexpected error occurred. Aborting. Error 403: --- begin server output --- You do not have permission to modify this app. --- end server output ---

I'm interested in how Google is calculating usage--and how they will bill for it in the future. I will post an update on what I find.