Monthly Archives: December 2009

The Busy Executive’s Quick Cloud Computing Reference Guide

As an executive, you may be hearing many different viewpoints about Cloud Computing; some of them promising significant IT cost reductions and reductions in capital expenditures. Similarly, you are hearing about the potential downsides of Cloud Computing, such as unexpected outages impairing your ability to operate or increased opportunity for data leakage and privacy and confidentiality breaches. Hence, I’ve put together this quick primer to provide busy executives with a non-vendor-oriented view of Cloud Computing realities.

You Are a Consumer of Cloud Computing Services

Don’t get caught off guard regarding all the technical complexities of developing and offering Cloud Computing services, the whole reason you’re considering this option is so others will take care of these factors for you. Although you still need to be an educated consumer, you don’t need to be in the weeds to ensure you’re not caught with your pants around your ankles if you decide to use Cloud Computing services.

With regard to Cloud Computing, you will either be renting an application, renting IT infrastructure or completely outsourcing a business function. You will see these referred to by a number of different names, such as Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service, etc., again, for you, if you’re trying to understand the differences between these you are too deep in the weeds. Of note, when we say IT infrastructure, we are including network connectivity, electricity, cooling, power backup, etc., not just a CPU, memory and storage, so you need to incorporate those attributes into any financial comparisons.

As an executive the key things to know regarding these options are:
  • Are you considering the Cloud for non-mission-critical capabilities? If so, then most Cloud Computing vendors will meet your needs without great concern. Your biggest concern should be ownership of your data, which has multiple components. One component is ownership in the eyes of the government. There are rules the government has to follow to gain access to your data when it’s stored on your premises, however, those rules have yet to be qualified if they extend to your Cloud service provider. The other aspect of ownership that has arisen with regard to Cloud Computing regards who owns the physical data representation you or your Cloud provider. While the answer should be dead-brained simple, the realities of this is unclear. Other things to be concerned about include extended outages that limit access to your data and the applications used to access that data and hidden costs for attempting to perform batch operations on your own data or incorrect charges if billing is based on usage.
  • If you are seeking to use the Cloud for mission-critical capabilities, will the Cloud vendor sign a service-level agreement that includes an option for non-performance financial penalties? To me, this is the dividing line for the role of Cloud Computing in IT. One of the advantages of Cloud Computing for a service provider is to take advantage of volume and economies of scale. If onboarding new customers results in legal agreements and the potential for financial penalties, its going to be difficult for them to offer their services at a reasonable price point. Hence, finding a Cloud Computing vendor that is going to provide you the assurances you need for a mission-critical application may be difficult.
  • Maintaining privacy and confidentiality is your responsibility. There’s a lot of discussion and speculation regarding Cloud security. The truth is Cloud vendors will most likely hire more highly-skilled cybersecurity experts than you will. Also, there’s a strong likelihood, based on statistics, that your network and systems are already compromised in some manner. So, the reality of the situation is the Cloud will not introduce a greater risk regarding confidentiality and privacy breaches and may offer a more secure environment than you can on your own. Moreover, it doesn’t matter if the breach happens in the Cloud or on your own premises, the repercussions will be the same to your business.
Vendors are Offering Me a Private Cloud Option

The private Cloud option is a way for vendors to take advantage of the fear, uncertainty and doubt surrounding the Cloud and sell the same wares they are selling to Cloud Computing service providers to you. As an executive, this is a real simple one for you; ask the question of your management team, “Were we already seeking to improve utilization of our existing data center investments regardless of the emergence of Cloud Computing?” If the answer is no, then when those private Cloud vendors show up at your doorstep, hold up your palm facing them and say, “talk to the hand!” If the answer is yes, then by all means, advancements in virtualization, storage and blade technology will provide you greater utilization of compute resources at a lower cost and, usually, lower energy consumption. However, take note, this change requires new skills, which equates to training and hiring of appropriate resources to manage this configuration. It also means that there is a greater likelihood for improper configuration, which can lead to outages that take longer to fix and make it easier to compromise.

That’s it! Simple, easy-to-understand and written to help the busy executive gain a handle on the key decisions regarding Cloud Computing without having to wade through all the technical, legal and financial details that are being bandied about on the Web.

JP’s Topsy-Turvy 2009 IT Year in Review

This time of year is a great time to reflect upon the last 12 months and see what has occurred as well as discuss the impact of the events on this year and next.

The Big News

The big news in IT this year has to be Cloud Computing. Like the result of a Gremlin fed after midnight, Cloud Computing turned into the Stripe of the IT world. As pundits and vendors raced to gain mindshare as a means of priming the economy-dulled sales pipeline, IT buyers were caught trying to figure out, “is this the next great frontier, or am I going to look like an ass for recommending yet another useless acquisition?” Interestingly, cost is not the major driver behind these offerings, but instead access to compute resources on demand that don’t require up-front capital expenditure. Now, they only have to figure out how to actually make it so their applications can work in the Enterprise, but shift to the Cloud for additional resources when needed. This should lead to some interesting Fail Blog stories next year since most companies barely have the right mix of resources to keep the lights on let alone actually architect (Webster actually lists this as a verb now, so if jiggy is a valid word in the dictionary, I guess I have to accept architect as a verb now) a distributed application capable of crossing compute boundaries. I will be watching a number of fronts, such as application virtualization and Open Virtualization Format (OVF) to see if these do anything to help with this issue.

iPhones were a big IT story this year. No, not the fact that businesses started using them as a platform, but that so many individuals actually opt to use their own iPhone paid for with their own dollars and often no reimbursement for their service plan instead of a nice corporate provided Blackberry. What’s next, people paying for their own health plans?

Of course, we can’t talk about big IT news without discussing the impact of social networking. It seems a day doesn’t go by that I get an invite to join a new network site or share data about where I am or where I’m travelling. The election of 2008 illustrated how digitally connected we all are as multiple candidates leveraged social networking to connect with voters and disseminate their ideas. In 2009, we began to see that impact start to seriously hit at the doorstep of IT. Gone are the days where Facebook and Twitter are blocked by the firewall, it’s now a requirement for businesses to extend their brand to these platforms. Employees are encouraged to Tweet and extend their networks via LinkedIn and collaboration has gone from buzzword to system requirement. I can’t read Arabic, but I think Al-qaeda even has a fan page now on Facebook (yes, that is facetious). The point being that social networking has changed the way we think about communicating and doing business, however, we need to educate users of these applications of the potential risks. These applications are ripe grounds for delivery of malware and phishing attacks; even if you don’t do anything other than update your profile and don’t limit who has access to view. Think about what’s in your Facebook profile: birthdate, pet’s name, spouse’s name, link to spouse, etc. I’m sure everyone reading this has used some aspect of this information as the means to access another computer system; and this is only one example of thousands. So, when social networking, remember, protection!

Finally, business intelligence has re-appeared on the scene. BI has been on and off the radar screens of business multiple times over the past twenty years. Perhaps it was the lack of technology to really deliver useful intelligence from the globs of growing and poorly-manicured data or the fact that when things go south business leaders look to the great Oracle (pun intended) to tell them how to run their business. Either way, BI is back in style along with men showing chest hair and platform shoes. It’s like the 70’s on acid. Unfortunately, I have some interesting news, unless you actually spend the millions necessary to get your data house in order, all the BI tools in the world are not going to provide you with an accurate picture of how your business is trending. Besides, you only need to look in your bank account to determine that. I do believe BI has some interesting applications when partnered with Complex Event Processing engines as a way to tell you that all hell has broken loose or is about to anyway.

The Ongoing Battles

Another year has passed and over that year the same 15-20 people have come out and debated the relative goodness/badness of SOA and BPM. Meanwhile, all the people actually developing solutions totally ignored what we had to say and many of them laughed heartily at us as they ran past us – straight into that brick wall. Hello? McFly??? Anyone in there??? We’re not here debating among ourselves for the sheer joy of it (although, it is really fun to watch @aleksb6 get his knickers in twist as @bmichelson pushes his buttons). We’re debating these issues because we realize there’s hundreds of millions of dollars at stake for businesses who are laboring to keep their users satisfied and don’t have the ability to fully understand all the nuances of developing large-scale distributed applications in a virtualized universe. So, why does some junior architect with three weeks of training from IBM or Zapthink believe they are capable of taking on a task that industry veterans cannot agree on a common approach for and be successful?

SOA is undefined, but it’s not a technology and is not a platform for developing applications, yet you’d better figure a way to get it on your resume if you want a job in IT in the 21st century. BPM is a methodology and a science, but it is not a toolkit or application. Both of these initiatives require experienced IT veterans with an understanding of enterprise capabilities, mission-critical deployment, all the –ilities (high availability, scalability, reliability, transactionality, etc.) and a comprehensive understanding of the business in order to properly align technology choices and directions for a successful outcome. This is a big picture thinker with the ability to drive that picture back down into attainable goals. We call them Enterprise Architects, you call them …. only when you’re already in trouble!

The Emerging Disruptors

And, now, the fun part of our little journey through IT-land, a look at what’s going to be hot or bite you in the butt next year!

Numero uno on the list of emerging disruptors has to be cybersecurity. A quick search into salaries for IT security personnel quickly tells the story of the state of affairs for this major league IT pain-in-the-rear-end. Most of you reading this probably already have a bot or malware running on a computer in your organization. These insidious beasts are being produced at a rate far faster than the software to recognize and eliminate them. Some of these are harmless, but some can be exposing critical flaws in your infrastructure that can be exploited by an individual with the appropriate skills facilitating access to your most confidential and private data. And, yet, the industry salaries for individuals with the capability to protect your networks and systems is below that of many other roles, such as Database Administrator (DBA), programmer, architect, virtualization engineer, storage engineer, etc. Obviously, protecting your information assets must be of minimal concern to you or you would be out seeking the skills of individuals or businesses that can provide you, minimally, with the knowledge that you have data leakage and, best case, close the holes and eliminate the problem.

It looks like Healthcare IT is shaping up to be a major land grab for software and hardware vendors next year. It seems that rising health costs and the government’s emphasis on lowering costs via electronic health records has moved the IT target to this vertical. I have seen a number of major software vendors establishing Healthcare IT groups within their sales and marketing organizations in an effort to ramp up for what is deemed to be the next great sales frontier. Well I hope this report doesn’t put a damper on those visions of grandeur. The report concludes that “health information technology has a modest impact on process measures of quality, but no impact on administrative efficiency or overall costs.”

Here’s one that my sources say to keep an eye on, IPv6. IPv6 is the next generation Internet Protocol. Many service providers will be switching to this standard soon because it provides them much more control over the number of Internet devices they can directly address and fixes many of the issues of IPv4. However, many of the IPv6 protocol stacks are new and have not been tested under full stress of a production environment. If you remember, it took Microsoft something like ten years to get their IP stack to a point where it was robust and mature. The IP stack is at the heart of every device that connects to the Internet. Changing this protocol is going to be slow and painful, but not changing soon is going to cause major disruptions in service as service providers are forced to use IPv6->IPv4 conversion, which at gigabit speeds is tedious and adds latency, not to mention that it will add overhead to the router for maintenance of multiple tables and increases memory consumption.

Metering and Instrumentation: Two Critical and Oft Forgotten Features of Cloud Services

An interesting facet of advancement is that it tends to limit know-how over time. At one time the mechanic in your local garage could take your entire engine apart, fix any problem and put it back into running order. Today, they can put a computer on the end, read a code, and hope it provides some understanding of the problem. Similarly, the application server revolution has unfortunately led to a generation of software developers that believe that the container can do all your instrumentation and metering for you, thus removing an impetus to build this into the application. These developers lose sight that the container can only tell you part of the story; the part it sees as an observer. If you don’t make more internals of your application observable, the most it can see is how often it hands off control to your application, what services your application uses from the container and when you application terminates control. Useful information, but not enough to develop large-scale real world services used by hundreds of thousands, or even millions of users.

I ran across a product the other day doing some research that I found very interesting. It was a service bus that had built in metering.

Putting the metering into the container is one way around the problem of every applications metering for itself, however, how many people are going to trust their services to this product company? Additionally, it would be very difficult to migrate this service in the future unless the metering interface was standardized or replicated in another hosting container. So, here’s a place where standardization of service offerings in service containers would be a very helpful feature; and something that needs to be the focus of Cloud interoperability.

Additionally, proper inclusion of metering and instrumentation interfaces into you Cloud service means that you have greater control over the granularity of the data produced through these interfaces. Most metering solutions I’ve seen today are very coarse-grained and often focused on infrastructure usage, such as cost per CPU cycle or gigabyte. What if you wanted to produce a service that had tiered pricing? This would require that those service operations provide the details of each transaction to a metering service.

Instrumentation is even more complex to manage than metering as it has the potential to introduce processing latency. If you capture too much instrumentation information then the service will not be responsive, but if you don’t capture enough, you may not be able to determine a pending outage until it occurs. I have seen first-hand the problems of poorly-designed instrumentation in a high-volume service.

In my first-hand experience, traditional system network management tools were used to watch the application performance including CPU, memory and storage, but were unable to determine that a process was out of control and eating up storage space quickly enough to shut it down before it completely brought down all services sharing that volume. In an elastic Cloud environment, where dynamic storage is configured to come online to minimize outages a process like that could eat up a large percentage of your storage array before you had the chance to unwind it. This was made even more complex by the fact that the service provider was unaware of the typical size of a transaction from each of its customers, so it could not assume a particular quota since that may limit a legal request.

These are real problems that could have been mitigated by an appropriate level of metering and instrumentation built into the services themselves. These sub-services could have inferred average transaction sizes and average storage usage and identified that a particular process was out of range in enough time for a human to get involved and stop the runaway process.

It’s interesting to see so much attention being paid to security in Cloud Computing since this was one of the most often ignored components for those implementing SOA-based designs. It seems that the immaturity of a particular technological direction is easily identified by what aspects of a robust, mature solution are ignored in emerging implementations. To ignore metering and instrumentation in the design of your Cloud services, or believe the infrastructure will handle this for you, to me illustrates the immaturity of Cloud Computing and a nativity on the part of those implementing Cloud-based services.

My Experience Developing A Google Wave Robot

This past weekend I set out explore some of the extension capabilities of Google Wave. One of the weaknesses that have been identified by many is the lack of integration with email. For me, in particular, because Wave is new, many Waves are being orphaned as those playing and testing out Wave don’t come back to the conversation for long periods, if at all. My goal was to use email as a means to bring people back to the Wave and keep the collaboration/discussion going in a single environment. Some developers are exploring letting users contribute from email, but in my opinion, that undermines the goal of Wave.

First, Kudos to Google for making it easy and straightforward to get a development environment ramped up quickly for developing extensions. Robots are based on their Google App Engine architecture, which allows users to leverage their Eclipse plug-in for App Engine development. For anyone that has ever developed a servlet-based application, the plug-in for packaging and deployment in the App Engine environment made the entire process quick and easy. Of course for fun, I had to set up an Ubuntu instance in my virtual machine environment to do this development.

After getting my environment configured, I downloaded a Java-based Robot sample that is the equivalent of “Hello World!” for Google Wave Robots just to ensure that I could compile and deploy. There was very little effort to make this work and test. Of course, not having a sandbox account yet meant that I had to use production Wave environment, so there’s now a lot of orphaned waves that I used for my tests.

With my application harness up and running, it was time to dive into the documentation and play. In my initial design I was planning on using the Wave itself as a storage mechanism for the subscription registrations, but as I learned, there is no guarantee that a Robot will have access to all Blips—the unit of data within a Wavelet—within a Wave. However, to learn that took a lot of review of the Wave data structures and data received from the Wave server based on the events I was processing. At first, I used the Wave itself to produce the artifacts for review since I was having issues getting my debug statements to appear in the application log. This was not a good idea as the Wave environment couldn’t handle the mass number of Blips being added at the speed the Robot was adding them. So, I had to aggregate the data and then put it all into one Blip. Making use of this data was also interesting since my formatting commands were being ignored. I finally figured out n works in a text blip for a newline, but never got the markup content to be produced properly.

All of the above could have been avoided if Google simply documented examples of what the input to the Robot would look like and described the structure of the data received. There’s still a major structure of the Wave content I still haven’t fully grok’d regarding annotations and elements. Since this is mostly for visual support, and I was focused on a non-visual tool, it got back-burnered for another day.

Once I understood that I could not rely on having access to all Blips in the Wave at all times, I realized I was going to have to establish some persistence of data. App Engine’s Data Nucleus Java persistence is excellent for this type of requirement. With little effort, I was able to create a mechanism that could store and retrieve a list of Java objects without having to use JDBC or proprietary persistence APIs. The other service that App Engine offers that I needed was email support via JavaMail. In the future, I will also try their XMPP service for Google Talk subscriptions.

After 2.5 days of effort, the outcome was highly successful. The command-line Robot that I called Checkwave is now published and available for anyone to include in their Wave. It support subscribe, unsubscribe and list functions. When you update a Wave all subscribed participants receive and email with text content of the Blip that was added and it includes a hyperlink that brings you back into the Google Wave environment with that Wave on screen.

A more technical description of the Robot can be viewed at http://checkwave.appspot.com.

Having developed a secure instant messaging platform at Ikimbo back in 2001 that allowed for robots and in-context replies, I am a big fan of these features in Wave. IM is great, but a conversation among multiple participants can become unwieldy to follow. The ability to explicitly address a prior message in context is a huge advantage over traditional IM systems. Moreover, the ability to facilitate this communication asynchronously is another major plus. Getting people to use a new tool, however, is a very difficult task. For me Checkwave was a critical tool to assist me in bringing people back to the Wave.

All in all, working with Wave was a pleasant experience and I look forward to seeing where Google takes this platform.  Some additional notes that people may find useful regarding Google Wave robots:

1.  Multiple robots in the same Wave can have unintended consequences.  When Cartoony and Checkwave existed in the same Wave, Cartoony would turn my text to graphics before Checkwave had an opportunity to read it, hence,  it broke the command-line capabilities.

2.  As the owner of information now entrusted to me by those using Checkwave, I realize that I must protect this data, but it also made me aware that any Robot you add has access to everything that occurs on that Wave.  So, you need to be careful which Robots you add to your Waves as you are providing implicit trust of any data provided through that Wave.