DevOps Zone is brought to you in partnership with:

My engineering career spans 25 years and includes research on relational databases, designing geographic map software, building email products, and creating scalable web applications. I am currently CTO at Rearden Commerce. Dan is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Focus on the Cloud, not the Clouds

01.26.2013
| 1725 views |
  • submit to reddit

There are a lot of very good conversations going on about the challenges with cloud computing. Storage is just beginning to mature in the cloud and there are many interesting issues around privacy, SOX, and PCI compliance. Nobody has clear answers yet on the security and compliance related issues. But I think for many enterprises, that may be a pointless dialog because it isn't federating their capacity into the clouds that is important but rather how to leverage the concepts and technologies from the cloud to improve their operational efficiency.

Before getting into complex discussions about the security challenges of using the cloud, I believe most organizations need to take a good look at how well their applications can operate in any utility compute model. Does your application currently support all of the following concepts easily?

Loose Coupling to Platform

Are your applications platform independent? Have you made them completely agnostic to the processors they require? Do they scale well from a single core to several cores? Have you optimized your memory footprint, making it fit well into a modest memory model? What assumptions do your applications make about operating systems? Directory paths? Available local disk space?

Ultimately, can you run your applications in a collection of virtual containers in your environment right now. The answer for many organizations is no. And until that is fully addressed, their ability to enter in cloud is largely non-existent. Forget about your PCI issues, your JVM footprint is keeping you stuck on your own hardware.

Crisp Packaging

Do you have a repeatable build and release process? Are your build targets well defined and self contained? Do they externalize their dependencies for tools to detect deployment requirements? Are the artifacts independent of their deployment environment (development, testing, production)? Are all environmental dependencies externalized and injected into your application at run time?

To leverage a utility compute model, you have to have components that are compatible. Everyone likes to draw parallels to the electricity model when discussing clouds. But imagine if every electronic component you purchased had different voltage needs. Failed to clearly identify their current needs. Forget about the obvious each coming with their own style of plug. We wouldn't have the ubiquitous electric utility model we have now. Yet few organizations are far off this analogy when it comes to the state of their applications.

Well Specified Management Interfaces

Do you have standard interfaces for expressing state of your application? How about for changing runtime behavior? Or detecting exceptional conditions? Or tracking activity for both debugging and analysis?

This is something I've covered in past articles but is worth emphasizing again. Operational control of the application requires a set of interfaces that follow the same rigor as your other API's. They need to be designed and evolved using the same principles and processes. And without such interfaces you will have a difficult time operating components, in your own data center much less in a compute cloud.

In Conclusion

The interesting part of this situation to me is these are all things you should be focused on accomplishing whether you are looking to leverage a vendor's cloud or not. These allow you to achieve lower cost of operation and better utilize your internal resources. And they do that without having to bring into question the challenges of privacy and security.

Published at DZone with permission of Dan Pritchett, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)