InformationWeek - Cloud Survey

Mike Healy, CTO at GreenPages, recently authored an article on the performance of cloud computing, published in InformationWeek. The thing that grabbed my attention was his big colorful graph titled, "What's the biggest bottleneck for performance of cloud based apps?"

Wow - great question, I thought. However, I was disappointed to see his results:

26% - Our own internal Internet bandwidth or connectivity

26% - Actual application/system design of vendor's application    (JRS - huh??)

21% - Overall Internet traffic

15% - Cloud vendor's Internet connectivity

10% - Don't know

2% - Other

========================================

I found this survey to be a warm, juicy, smoking pile of crap. 

... Deep breath ...  ... Sip of coffee ...

Computing infrastructure is generally considered a 3-legged stool: 1. Compute power (cpu/memory) 2. Network and 3. Storage. On top of this we lay down our software architectures (n-tier, interpreted/compiled, etc.) If you're going to look for a performance problem, this is a decent way to slice it up. What you don't do is offer participants 3 answers that all lead to "NETWORK". Although, I did enjoy my course in college on, "Misusing Statistics to Your Advantage". Ah - those were the days. 

Now, I don't have any fancy pie chart - or an actual survey... but I do talk with LOTS of chief architects on their cloud performance. Here's what I hear:

1. I'm happy with the performance 

  -- (yes, we did some minor rearchitecting to take advantage of cloud properties)

2. We're not going to the cloud for performance reasons. 

  -- (These guys typically have high performance SAN's and feel like they'll melt down the DB/messaging tier; and yes, cloud providers are working on this)

3. The application didn't perform 1:1 relative to our on-premise due to the cloud virtualization 

 -- We solved this by adding another node to the tier. 

4. Our application is a web of modules and we only moved some of them to the cloud. Now we see latency issues between on-premise and cloud deployed modules. 

 - First, if it's a 'real' company, they already have a dedicated line to the cloud provider. Second, they're probably reviewing the distributed computing chattiness and trying to figure out if they can change the message granularity, caching, etc. 

Mike continues to discuss WAN optimization as it relates to cloud (JRS - ???) and other jibber. People - there are real issues related to cloud performance. Perhaps it's time to pull out your "Introduction to Computer Science" book and throw away your copy of InformationWeek. 

The Relationship Between SOA and Cloud Computing

I thought I'd weigh in on the chatter going on related to SOA and Cloud Computing. For some reason, people want to hold all day events that draw links between the two. This perplexes me a bit, but what the hell. Here's my take.

• If you have services (as in a SOA), you need to run them on some infrastructure. 
  
• The infrastrcutre can provide goodies like auto-scaling, self-service provisioning, etc.  ('cloud properties'), or not.
  
• If you put your services in the cloud, your services inherit the properties of the cloud. 
  

The End.

If this all seems a bit obvious, it's because IT IS. 

rPath Introduction to Cloud Computing

I really liked the analogy of buying a car vs. renting a car vs getting a 'metered cab':

Cloud Security - Physical

The chatter on cloud security continues:

http://gigaom.com/2008/12/11/cloud-security-the-sky-is-falling/

http://4sysops.com/archives/is-cloud-computing-secure-pro-and-contra-cloud-security/

My company, MomentumSI, has been working on a template RFI/RFP for cloud providers. One of the sections is "Cloud Security - Physical". This doesn't cover logical (information, passcode, on-wire, etc.)

I'd love to get any feedback on the following questions:

1. Describe the concentric control boundaries (whole site, building and sensitive areas)
2. Describe use of authentication & access control (keys, badges, facial recognition, voice recognition, hand-prints, iris scans, signature analysis, etc.)
3. Describe exterior walls and windows specification (thickness, Kevlar lining, bomb resistant laminated glass, etc.)
4. Describe buffer-zones and retractable crash barriers
5. Describe internal partition walls and their ability to limit the spread of fire and provide separate access zones
6. Describe capabilities to prevent unauthorized access under raised floors or above false ceilings
7. Describe the securing of cages and racks
8. Describe the security procedures taken on employees and contractors of the facility (background checks, drug checks, etc.)
9. Describe the process for rotating id’s or passwords after certain time periods or events (employee is fired or quits, etc.)
10. Describe the security procedures taken on non-employee visits.
11. Describe the process of physical and virtual key issue and revocation.
12. Describe capabilities related to proactively finding explosive devices.
13. Describe your surveillance capabilities (cameras, motion detectors, micro-switches, pressure pads, alarms, etc.)
14. Describe the security related to your mechanical areas (UPS, external cooling, etc.)
15. Describe the use of security guards, their training and enforcement capabilities.
16. Describe the use of independent security audits including depth, frequency and the availability of the results to clients and prospects.
17. Describe use of transmitters & receivers, including cell phones within the center.
18. Describe how any violations detected will be recorded and reported back to the customer base.