CloudNavigator

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.

 

Two or three years ago I purchased a Zonbu mini.  This was a little, relatively inexpensive, small form factor, ITX based system.  It consumed very small amounts of power, was easy to set up and use, and satisfied an immediate need in my household for another web access point and general purpose system.  The main selling point, however, was that none of the storage (except for a compact flash based cache) was local.   I wouldn’t have to worry about backups.

In fact, I can do backups of important files from my other systems by copying them to my Zonbu and saving them there.  (wherever "there" is)

The term "Cloud Computing" didn’t really exist when this product emerged.  Zonbu was pioneering consumer cloud storage before it even had a name.  They haven’t been standing still over the past couple of years.  They added a laptop, and then higher end systems.  Now they even have a software only solution.  And you can try it out, without the personal storage space, of course, for free.

The Zonbu system includes a handful of simple games, the Open Office productivity suite, a browser and a few other utilities and tools.  It is all pre-configured and easy to use.

And they take care of your backups for you.

Your data is safe, stored in an encrypted format somewhere in their cloud.  You have the option of storing the data without a recoverable password, or with a recoverable password (meaning; do you want the folks at Zonbu to maintain a ‘back door’ to your data, or do you want to have the only key?  It is up to you.)

They also added a storage area that is accessible over the web.  You can easily publish web pages and other content, or use it as an interim waystation when to copying files from your Zonbu to somewhere else.  

There are mechanisms to obtain root on your Zonbu if you really want to customize the installed software or just hack it.  I haven’t had the need.  It works well enough as-is, out of the box.  It would be nice to have a newer version of the Firefox browser, or maybe have the option to use Opera or Google’s Chrome for a browser sometimes.  Otherwise it does everything it promised and I haven’t felt the need to have it do more.

Zonbu customer support is great!  They’ve been very responsive and helpful the few times I’ve needed them.  They even took care of a hardware issue I ran into with my wireless interface with minimal fuss and remarkable turnaround.

If you are looking to spend some money and go with the herd, then a Microsoft solution is probably better.  If you are looking for a high quality (and pricey) solution, then go for a Mac.  If you are looking for a flexible desktop solution with many options, then maybe try a PC with Ubuntu.  If you are looking for something that is simple, doesn’t require a lot of maintenance, is inexpensive, and just does the (basic) job, Zonbu may be the right solution.

I think over the long term this is the future of basic desktop computing.  You can personalize your environment, and yet the bulk of the hard part (security, integration, & backups) are managed centrally by professionals.  This is a slightly different model than the web based application suite [ accessed from a full fledged PC ].  At least until HTML 5 is ready, programming complex desktop applications for the web is much harder than programming for the desktop.  There are significantly more desktop applications already available than web based ones.  The Zonbu-like solution will work with lower bandwidth and higher latency environments, something which can be another challenge for successful web based "desktop" application implementations.   Desktop based (cached) applications with encrypted (cached) storage seem easier for an organization to contain entirely "inside" their virtual borders, and to license, and therefore may be much more palatable.  

This is basically the ‘thin client’ model, which has waxed and waned in the world of system architecture over the years. What makes this model really work is the technology has finally caught up with the idea.  The synergy of being able to leverage the breadth of applications already available on the Linux desktop platform, with the cloud storage technologies, on low power, inexpensive, consumer friendly small form factor hardware bears at least watching.

 

Another interesting, and often overlooked, use for an ESB is to support Functional Tests for other development efforts.  Because of its plethora of connectors and relative ease to configure, if you have a development project that relies on external services, you can set up an ESB to ‘mock’ those other services.   It can emulate a (brain dead) database server, an application server, a web server, email server, bizzare application server, or whatever else you might need.

The ESB can either come up as part of your build, or be configured somewhere, and left running, to dummy whatever it is you might want to run quick build-time tests against.

 

 

 

Here is another good article on the F5 blog site regarding the necessity to understand your cloud (at least a little):

 Cloud Computing: Location is important, but not the way you think