In my previous entry regarding Cloud Computing, I discussed briefly one of the major reasons why organizations are turning to the cloud, saving costs. I pointed out some of the issues involved in achievable that goal.
While I also consider the possibility of cost savings associated with Cloud Computing important, I believe other implications are more important in the long-term. I discuss a second one today, and will touch on two more in the next few blog entries.
When we start thinking about moving applications to the cloud it leads us to reconsider how we develop applications. This change in thinking has, as a foundation, the move to object oriented design, and has been encouraged by a change in conceptual ownership. I talk about both of these in this post.
OBJECT ORIENTED DESIGN. First, I want to emphasize that I am far from an expert in software development, let alone object development, and all of the implications. As usual, however, this does not stop me from having opinions.
When I was a beginning programmer, when I actually had jobs that resulted in results as opposed to my current responsibilities to produce insubstantial policies and hard to measure roles as a manager or heaven forbid, a leader, computer programs were written functionally. That is if you were writing a payroll program you would consider the steps one took to do the payroll:
- Hire a person
- Enter the time for the week
- Process the payroll
And so forth.
In more recent years, the focus changed to objects. That is when designing that same payroll program you might start with what were the ‘objects’ that would be involved in the system:
- A person
- The personnel record
- The check
Where an object could be a ‘thing’ or a process. You would then work through what information that object might expose and/or what actions the object might do or have done to it.
Cloud Computing lends itself well to the concept of object oriented implementations. It is likely to be difficult to think through how to do something functionally in a cloud, e.g. how do you divide up the function between your desktop computer and the work being done remotely over the Internet. But it is not so difficult to think through putting some objects in one location and some objects in the other. While you are still left with the issue of how to find (“discover”) an object and how to get them to ‘talk’ that is send messages to each other, these are solvable problems.
While I am sure I am over simplifying the concept, the way I look at it this is the basis for what has now become Service Oriented Architecture (SOA).
If you consider the object as a service, that is, it provides a service to someone (or something), then SOA allows us to take a coherent approach to putting objects in the cloud and provides a discipline regarding how they interface.
OWNERSHIP. As important as how one develops software applications is the change in how organizations and developers look at the ownership of the result.
When something is developed in-house and implemented on the organization’s own computers in their own datacenter, there is a tendency to look inward for everything associated with the application. One is less likely to think about using external resources to optimize any of these activities.
However, when the application ends up partially or completely housed in a cloud, whether private or public, then the orientation for planning inevitably starts to focus on how to optimize the situation using at least some resources that are not under internal control. That is, it forces developers to think about the external provisioning.
Once one starts down that path, many additional options start to be under consideration.
What about using someone else’s services/objects to supplement my development? What would I have to do when designing and implementing my application to take advantage of such external resources?
Internet/cloud based providers have incentives to make this kind of interaction easier since this enhances their value-add. Mash-ups, http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid), which can enable very creative solutions with significantly less development investment have become increasingly commonplace.
In summary, the second value-add of the movement to cloud is the change in approach to architecture of and implementation of applications.
I talk about and eventually will write about the movement from Ptolomaic, earth centered, to Copernican, sun centered, to Warholian, nothing centered, thought processes. This is the movement we are undergoing in application development, hastened by the move to the cloud.
What we design for today is not what will exist even two to three years in the future. The impact is only starting to be understood.