CloudNavigator

Here is a short posting titled "How Cloud Computing Hurts Venture Capitalism" which talks about the impact the new Cloud Infrastructure providers have on startup company strategies. 

ComputerWorld released Part Two of The Case Against Cloud Computing yesterday.  In part two they take a close look primarily at the challenges meeting audit and compliance requirements when some of your infrastructure is outsourced to a Cloud SaaS provider.

I’m not convinced those challenges are that much greater with a Cloud architecture than any other.

Audit requirements (legal, financial, or otherwise) all boil down to being able to answer the same basic set of questions - "Who had access to the data?", "When did they have access?", "Who changed the data?", and "When did the data change?".   The requirements are really about the DATA, not the architecture.   So, can you answer those questions in a Cloud SaaS?  Sure.  Perhaps you will need to include the vendor, perhaps not.  (Is the data encrypted while it is in the cloud?)  Specific methodologies for answering audit questions will necessarily vary depending on the architecture.  For example in a Cloud application you might now need to include proxy server or firewall logs.

Compliance analysis is differentiated from audit requirements in that sometimes you want real-time feedback if there are policy violations.  In the case of data abuse or other unauthorized data access, such metrics and monitors would probably need to be designed along with the cloud application similar to any traditional application.

Data Backup and Disaster Recovery processes, which are sometimes driven (rightly or wrongly) by meeting audit  requirements, could be serviced via a well negotiated SLA which would include contract mandated tests.

Change Management, is also sometimes driven in part by audit requirements (rightly or wrongly).   By their very nature, Cloud insfrastructures are usually fairly dynamic.  A rigid change micromanagement bureaucracy could quickly erode any advantage Clouds offer.  Just like some of other processes supporting Cloud infrastructure, change management is going to have to adapt as well.  Step back and consider the reasons for implementing Change Management in the first place.  How can some of those same goals be achieved (can they be achieved?) when you are deploying in a Cloud?  Rather than focusing initially on jamming your legacy processes into the new paradigm, focus on the real problem.   If the Cloud is well engineered, then maybe changes within the Cloud, as long as they are within engineering tolerances, need not be subject to more process than simply logging the internal change.  Grander activities, such as deploying new application releases and fundamental changes in the architecture would need bureaucratic oversight.  Where do you draw that line?  Certainly it is something else that will have evolve and require flexibility to succeed.

 

 

 

 

ComputerWorld published  The case against cloud comuting, part one  yesterday.   The arguments are mostly about how hard it is to make the paradigm shift for the external Software as a Service (SaaS) cloud solutions.  The headline implies the arguments apply to any of the related cloud computing technologies, but they don’t really.  The article is a little bit whiny: "Its too hard!".  No doubt there are challenges and required new ways of thinking about how to manage things with the new architectures.  No doubt there are legacy vendors and technology investments that are going to suffer.  No doubt there are old timers in IT who like things the way they are.

Some of the arguments sound exactly like the arguments we heard with the emergence of distributed computing.  A paradigm shift is underway and the younger, nimbler, and adaptable IT enterprises are going to leapfrog into the new age.  Mainframes never went away, and may never go away.  Legacy static architecture and fat clients aren’t going to completely go away either.  Sometimes for good reasons, sometimes simply because they have momentum.

 

Microsoft is hoping to position itself as a cloud infrastructure and application services vendor.  They are investing heavily in new datacenters, according to Business Week.

One of the interesting things in that Business Week article is that Microsoft has taken up Sun’s Blackbox idea, to build what I would describe as "clouds in a box".  These are modular data centers tightly packed into highly engineered and  (mostly) self-contained shipping containers at a much lower cost per-square-foot to implement than a traditional data center design.   I’m sure we’ll be hearing a lot more about this initiative over the next couple of years.

I think one of the biggest challenges Microsoft will have to face with this computing model are the changes to software development methodology and product life cycle management that also have to take place.  I’ll post more on this later, but in a nutshell, if you deploy a product on a highly dynamic, flexible architecture, you have to be prepared to have dynamic and flexible product development and management techniques as well.   (ie, something like the Agile development model)   For organizations like the software development bureaucratic behemoth that Microsoft is, such changes will almost certainly be fraught with some paradigm shift pain.