CloudNavigator

Most web service managers and architects I talk to describe their architecture as a "3-tier" model, meaning they have a web server tier, and appserver tier, and a database tier.  However most such architectures in fact turn out to be much more complicated with ESB components and other connectors, access control services, mulitple layers of data sources, firewalls, intrusion detection systems, audit servers, disaster recovery support and more.   Sure there are pieces which fall neatly into one of the classic three tiers.  However there are a lot of gray areas, side-bars, and odd pieces in the typical architecture as well.

Many popular web content management systems such as Django are particularily hard to fit in that model.

The traditional "Load Balancer" was a technology that mapped neatly into the spaces between the layers in the 3-tier model by providing horizontal scaling for at least the web layer and the appserver layer.   Nowadays, the technology has morphed what F5 calls Application Delivery infrastructure.  Intelligent adaptive traffic management which is almost a "tier" in and of itself.   In a lot of ways, deployment of F5 technology can render the webserver front-end to your application largely irrelevant (obsolete?).

Recently I came across Harbor which obliterates the traditional box based appserver layer by letting you write Java programs and then deploy the various classes to wherever in the cloud it makes sense to run them.  Cool technology!  The developer becomes abstracted from having to know where in the infrastructure they are running.  The application becomes highly flexible, adaptible, and hardware/platform independent.  Perfect for deployment in ambiguous Clouds.   Harbor seems cutting edge.  Clearly it will take some time for a paradigm shift such as what it represents to really catch on.

Throw in a neo4j data model (or two) - which I blogged about earlier and maybe it is time to finally break out of  the old 3-tier web architecture box and retire the concept….  

 

 

 

 

Is the Relational Database Doomed?  is the title of a very interesting article exloring the pro’s and con’s of "key/value" databases, a common data structuring technique in Cloud Computing.  Clearly data management and modeling is evolving along with the technology we are using to store and access it

Due to the fluidic nature of the Cloud Computing architecture, your data could move around.  A system has to be devised that lets you keep track of where your data is, when you need it.  Traditional Vertical Scaling (building bigger and bigger boxes) has natural and obvious constraints.  It is not a model that lends itself well to cloud models.  The "key/value" data model described in the article is one technique for organizing certain kinds of data in a highly scalable array of inexpensive computing resources (a cloud).

In the comments to the article someone points out neo4j, an open source database technology which models data using Graph Theory techniques rather than as Tables.  As someone who really enjoyed graph theory in college, this data modelling approach really intriques me and will require much closer study as time permits.  (The graduate level Graph Theory course I took as an Undergraduate at U.Mass Lowell was one of the most challenging, mind expanding and interesting classes of my undergraduate and post-graduate education.)

 

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.

 

 

 

 

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