The Tech Evangelist Leading IT Innovation One Blog Entry At A Time

24Dec/092

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.

4Dec/091

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.

2Oct/092

The SOA (& Cloud) Funding Dilemma

Lately, and primarily among government users, I've been hearing about a potential clash of bureaucracy meets technology when it comes to funding shared services.  It seems that the current government procurement and funding processes do not favor strategic sharing of software services as an outgrowth of a single development effort.  I imagine that this issue might also arise in some large organizations where the business units are funding development using a self-funded IT organization, but I have yet to hear any specific stories coming from the private sector regarding this issue.

While there seems to be a number of workarounds to this problem, the basic issue still remains.  If one government customer funds the development of an application out of their budget, and in developing that application, it is decided that one or more services could be of use to other government customers, there may be budgetary concerns for actually developing, hosting and maintaining those services for those that are not the original funding customer.  Moreover, it becomes questionable how to go about adding features to those services when the requests are not coming from the original funding customer.

With all these government agencies pushing SOA in their IT strategies, one has to wonder, what exactly are they asking for?  If the goal is not to remove redundancy within a single department and within a single agency--we're not even focusing on cross-agency here--as a means of reducing costs and providing a single means of delivering a business function in a non-ambiguous manner, then what is the goal?

From my own personal experiences, I believe certain agencies do desire to achieve the benefits of SOA, while others are simply seeking the benefits of component-based architecture, which is flexibility and agility in application design to lower costs of maintenance.  However, due to "management by magazine" approaches in IT coupled with the "slap SOA on everything" mandates, agencies that are capable of only benefiting from component-based architecture--because of the procurement and funding issues or just basic needs--are now requesting SOA and ending up spending a lot more to develop a simple application than they should have in the first place and getting a lot more complexity and reliance on middleware infrastructure that is, at best, using a sledgehammer to kill a flea.

Now, most of this entry discusses the issue with regard to SOA, since this is where the problem has really become apparent recently.  However, it's not too far of a leap to envision that Cloud Computing, that bastion of shared compute power, is going to have similar and more complex hurdles to overcome with regard to maintenance and operations of applications running in the Cloud.  At the end of the day, someone responsible for budgeting today is going to have to figure out how much is required to support and maintain one of their applications next year.  That may not be too difficult a task when they are the only  group consuming that application, but the budgeting process is far more difficult when that agency accidentally becomes a SaaS provider to other agencies and departments interested in using that application.

Got any private or public sector stories regarding how the budgeting and procurement processes are hindering the strategic value SOA?   Please share them with me as I am really interested in understanding the full boundaries of this issue.