Sunday, June 10, 2012. New York City.  Tomorrow kicks off one of the largest Cloud computing events in the United States, the Cloud Expo.  My esteemed colleague, Bill Zack, will be covering patterns for Cloud Computing and kindly, the organizers have offered him a free pass to distribute to last minute attendees who would like to hear his talk, and also attend the show.

I’ve been following High Performance Computing, Grid Computing, Cloud Computing for many years, both in the Middle East and in America.  I have taken these observations and included them as part of Slalom New York’s Cloud Computing Strategy.  Here is a list of five opinions on Cloud Computing in New York City.

1. Amazon Web Services viewed as the top player for Cloud in NYC

2. IaaS is sometimes another name for old school hosting

3. Decades old Software Patterns may not be applicable in the Cloud

4. The line between IaaS and PaaS blurs every day

5. This opinion will be stated during the week of Cloud Expo

See previous: Infrastructure as a Service sometimes is another name for old school hosting

At the upcoming Cloud Expo, Bill will cover design patterns for Cloud Computing, however, here is a a light analogy that I like to use to explain what we mean by “Decades old Patterns may not be applicable”.

In the past, performance was king. The faster your applications ran, the better the design. The better the architect, the better the developer.

In the Cloud world, performance is a commodity. With elastic cloud, it’s easy to expand and contract your application to run faster or relax against processing demand. It’s not even just easy – you don’t have to think about it.

Consider this scenario. Let’s say you have a giant image file of a high resolution photograph (assume it’s big, roughly 2 GB) and you have been asked to superimpose a Bend Sinister on top of it (think Ghost Buster’s Logo).

In the past, the fastest way to do this would be using vector based graphics. Take the whole image, toss it up into memory, and then use an algorithm to draw the Bend Sinister on top of the image. Super fast, very performant – you get lots of pats on the back.

Today if you did that in the Cloud, you’d get some frowns. Compute time costs money. Nothing is free in the Cloud. Even storage costs money, and storage is cheaper than compute.

So in the Cloud, this same requirement for a Bend Sinister drawn on top of a photograph, may be best designed by creating two images – one of the original photograph and the other of a Bend Sinister. This keeps the drawing in storage, rather than compute. Cheaper. Then superimpose them onto one another.

There are many scenarios were traditional software design may need to be revisited to maximize cost and efficiency in the Cloud. Usually clever performance design techniques are the first place to start.

See next:

Full summary here: Five Opinions on Cloud Computing in New York City

Are you a developer? If so, look at this Far Side cartoonReplace the word “Ginger” with the words “token ring” and “extension methods”, and now you will get a good appreciation of what human tharn looks like. Human tharn is what non-developers feel when you, as a developer, speak to them in Ginger-speak. 

Try speaking code in poetry. Dress your developer avatar up in rainbow tie dye, or devil horns, but whatever your do, don’t talk code to non-developers.

Whatever you do, explain dev stuff to non devs in Code Poetry.

Lesson 1: “We need to put DRM or some sort of tunneling VPN in and out of the transfer into Azure Table storage”

Instead tell the project manager, “If you don’t do what I say, someone is going to hack them, just like we hacked “INSERT OFFICE GAME RUN BY YOUR CEO”!  Then what’s going to happen is that all their private videos made only for “INSERT SPECIAL PEOPLE OF AUTHORITY” will show up on youtube!”

Lesson 2: “Let me explain token ring. BLAH BLAH BLAH BLAH BLAH, token ring BLAH BLAH wide area network BLAH BLAH BLAH OSI model BLAH BLAH BLAH frame check sequence BLAH BLAH”

Instead tell the project manager, “A token ring is a bunch of people standing up in a room yelling at one another until they all shut up and only one guy talks.” 

All credit for that goes to Bill Zack, author of Cloudy in New York. Any error was mine.

Lesson 3: “Let me show you how to create an Entity Relationship Diagram for the business requirements you mention”

Instead tell the project manager, “Let’s break this out into nouns, verbs and adjectives using the technique so cleverly undocumented Chapter 3, of the series Women Build 

Chapter 3 will be written once there is sufficient demand.

Lesson 4: “I don’t know why you don’t understand Extension Methods, clearly they are the better alternative. Let me break it down into the differences between Imperative and Declarative Code and you will see that the Cloud economics on the alternate route are negligible and that Extension Methods are superior. It is not my fault that this knowledge transfer session is taking so long and that I am, as some people consider, genius.”

Instead tell the project manager, “Let’s say you want to wash a very big rock.  You could put the rock in the bathtub, then go to the well, fill up a bucket, dump the water into the bathtub, and then go back to the well and get more water, and repeat it until you have enough water in the bathtub to wash the rock.  That’s one way to do it and it will definitely wash the very big rock.”

“Or, what you could do is hurl the big rock and skip it a million times across the surface of a large ocean.”

“That’s a better way to do it.  Extension methods.”