"Overall, 73 percent of respondents said they need new skills to deal with cloud" claims a study interviewing 10,000 security professionals by Frost & Sullivan to be presented at the upcoming RSA conference.  

I think a big part of the confusion is the hiding of infrastructure design that cloud vendors engage in.    Part of the hiding is clearly to retain intellectual property ownership, but when you take into account discoveries like the recent one at Stonybrook that Rackspace cloud compute power doesn't scale with instance size (in fact, it's flat), the dark underbelly of the obfuscation comes into view, which is sowing FUD (fear, uncertainty, and doubt) among customers for competitive advantage.   There are cloud providers (ENKI included) that are transparent about infrastructure design and resource allocation, but they are in the minority and don't include "former bulk hosting companies" like Rackspace.  

For security to be effective, the security design cannot be based on assumptions about the infrastructure but rather an accurate understanding of what elements are involved.  There's no way to secure unknown infrastructure as a user or consultant - you have to rely on the cloud vendor's promises and guarantees, which in many cases are nebulous.

One of the biggest tragedies - and one that ENKI is often called upon to work around or repair after the fact - is that our customers don't write their applications for cloud deployment before they come to us wanting to deploy them.    Often, other considerations dominate, such as rapid time-to-market, inadequate staffing to rewrite a demo application for production, or simply not knowing what is required.   The result is that our successful customers have often had meltdowns where their architecture just couldn't cope with the traffic, no matter how much computing power was thrown at it - if it could even make use of the power available.  

I've been beating the drum of efficient software for quite a while, starting with my article series on data center power consumption, but for applications that have to scale rapidly or highly, efficient software is not just desirable, it's required, since the consequences of writing inefficient software can have significant impact on your bottom line.  I could go on about this, but today I want to talk about a different kind of efficiency, which is being able to scale efficiently.

Fundamentally the requirement is that you can add more virtual machines to your deployment and use them effectively without incurring unnecessary overhead or failure-propagating dependencies.  This involves taking maximum advantage of parallelism, which includes avoiding some of the pitfalls that prevent it from working properly, including maintaining state in one of many parallel servers, having unneeded interdependence between servers or cores in an application, and relying on execution order across parallel instances.

What brought up this discussion was that I accidentally ran into a year-old article on building cloud-ready multicore applications.   Hopefully you'll find it as interesting as I did.