Cloud Computing Pragmatics
In October of 2009 I was interviewed by GovIT Journal and in that article I presented my view that Cloud Computing is highly dependent upon the network. The actual quote given was, “Which just goes to show, the telco providers still hold all this stuff by the balls!” More than ever, based on my work over the past four months as Merlin International’s Chief Architect, I still believe this is a critical and pertinent factor regardless of your Cloud Computing architecture.
Indeed, I have relished these past few months because they have presented me with the opportunity to delve deep into the muscle tissue of Cloud Computing. One of Merlin’s key areas of success has been in providing networking and data center hardware and software. While many architects can talk a good game about Cloud Computing, few have actually walked the stack top to bottom and actually touched the underbelly of the beast. Shoot, I even became a Riverbed Certified Solution Professional, a wickedly-cool WAN optimization product and am now focusing on Network Appliance certifications next. Understanding these “organs” of the Cloud truly provide unmatched insight into what is achievable and what is hype.
Meanwhile, I’ve been deep in muck gaining real insight into what Federal government customers are dealing with in trying to provide agile infrastructures to support the growing and changing needs of their user base. It’s real easy for pundits to step up and present a vision for Cloud Computing as a configurable resource that’s capable of meeting all needs, but I really believe that is a misnomer. In fact, more than ever I believe that we need to specialize Clouds to support a specific purpose. For example, I advocate that users need separate Cloud Computing infrastructures to support their full-motion video needs and their back office applications and that these should not live on the same Cloud infrastructure; especially if utilizing multicast video capabilities.
Vendors spewing forth mumbo-jumbo about creating a group of virtual machines and deploying them in an automated fashion seem to be heavily focused on new and simplistic database and business applications. Anyone doing heavy lifting on their network, dealing with saturated WAN egress points and leveraging legacy applications know that this is a pipe dream designed for the R&D lab. Putting together a Cloud Computing architecture requires a solid Enterprise Architecture effort in which the AS-IS and TO-BE architectures are fully understood and documented and there a roadmap that describes how to move from one to the other inclusive of details, such as security, auditing, monitoring, utilization, tuning, etc.
Oh, and let’s talk about security. I’m going to be putting forth an entire blog entry shortly on the real issues with defending against cyber threats, but, needless to say, building out a Cloud Computing solution before you even implement a single sign-on solution and identity management program is a recipe for redundancy and increased overhead at a minimum and breach in the worst case.
In this article, Hord Tipton, executive director of (ISC)2, the International Information Systems Security Certification Consortium, and ex-CIO of the Interior Department and Bureau of Land Management, makes an important point that security must be baked in from the start. I couldn’t agree more. Putting a few Intrusion Prevention Systems (IPS) or Data Loss Prevention (DLP) tools as the egress/ingress points cannot stop one of the biggest security flaws we have because they are designed into the core of the applications that manage and control the data. The move to the Cloud only exacerbates these problems. However, I will admit the move to Cloud offers a tremendous opportunity to deliver security as a service and then port the applications to the new architecture to minimize the risk of potential breaches.
One thing is for sure, this Cloud puzzle is large and offers a great opportunity for efficiencies. However, we need to be pragmatic in our approach or we risk exacerbating current problems instead of solving them.
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.
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.
- 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.
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.
The Reason Enterprise Architects Should Study Economics
Economics is the social science that studies the production, distribution, and consumption of goods and services and aims to explain how economies work and how economic agents interact. The really interesting thing about economics is that getting the right answer requires that you pose the right question. That is, if you choose to make conclusions based on casual observations of explicit cause/effect relationships, then your conclusions will seem logical and sound to most who will review them. However, only by ensuring that the cause/effect relationship holds up in the case where casual variables are changed, can you be sure that you have truly observed a phenomena and that the cause is accurate.
I've been reading Freakonomics (looking forward to Super Freakonomics when I'm done), and I'm astounded at how well Steven Levitt's approach to Economics could fit the needs of Enterprise Architecture. For example, in Freakonomics, Levitt uncovers the truth regarding many long-held beliefs, such as most drug dealers live at the poverty line or how little parenting actually impacts the outcome of a child. What helped to uncover these facts was asking the right question and identifying which variables in the equation needed to remain static to ensure a valid outcome. In many of the cases, Levitt undermines what many other Economists, experts and pundits before him rolled out as proven facts and only due to his keen mind and his approach to formulating the problem domain was he able to uncover that which his peers could not. To keep us focused, I won't discuss here how he discovered why violent crime rates dropped in the 90's, but needless to say well-held beliefs as to why were shredded by Levitt's innate ability to target just the right variables and "run the numbers."
If we apply Freakonomics-type analysis to current information technology markets, such as Cloud Computing, based on experts and pundits one would readily equate that: a) public Cloud Computing models offer a more cost-effective way to acquire computing resources; b) it's better to rent software than to own it and; c) in the future, all computing will be paid for based on usage versus ownership. Similarly, if you read the headlines of many tech publications, you would believe that: a) everyone is doing SOA; b) there are many successful SOA deployments and; c) SOA is the only approach to developing systems that you should consider. None of these conclusions are true in all cases, maybe in no cases, and, in fact, the real numbers would probably tell a very different story [I'm leaving this as an exercise to the reader since I want to focus this piece on the approach to EA, not the application of analysis to these issues]. These statements are being made arbitrarily based on extremely small sample sizes and are as valid as looking around you at a large business gathering noting all the iPhones and Blackberries, and concluding that iPhone & Blackberry must outsell all other phones, when in fact, their combined market share is a mere 3.0-3.5% of the overall mobile phone market.
In actuality, I see a lot of IT decisions being made using what, seemingly, is no more exploration than was used to determine that iPhones & Blackberries have a leading market share. It is the Enterprise Architect's role to ensure that the selection and approaches toward development of systems are sound relative to their business, not just other businesses. Moreover, where decisions are based on the work of other businesses' success, those successes need to be properly vetted to ensure that there is enough commonality between efforts, such that you could make the leap that your business will see similar results. Finally, assumptions and theories need to be tested by properly identifying the variables that need to remain static and then comparing; in essence normalizing the question to be homogenous in all situations. For example, in Freakonomics, Levitt points out that in order to prove that the numbers behind why violent crimes dropped in the 90's he needed to review similar trends of violent crimes in areas that had not made the purported changes that led to the large unanticipated decrease. When the trends were normalized to remove noise and anomalies, it was shown that those factors seemed to have relatively little impact on violent crime decrease.
This brings us to the all important question, "how do we demonstrate the value of Enterprise Architecture?" Unfortunately, you cannot demonstrate the value of Enterprise Architecture if you cannot monetize or enumerate the value of all possible choices relative to the choices that are being recommended or those that have been made. Moreover, it's critical that these analyses are carried out over enough time that short-term wins don't supersede long-term potential gains. Thus, it is here that Enterprise Architects, especially those we call Chief Architects, truly show their mettle. It is their experience, coupled with the ability to focus on the right set of variables, understanding the impact of change of those variables and being able to communicate that in a way that allows the business to make effective business decisions, which sets top notch practioners apart from Sr. Software Engineers that the organization placated with a title to keep them happy so they wouldn't leave.
My Prediction of Cloud & SOA in 2005
Okay, maybe it's petty and I'm just tooting my own horn, but I found this old article I wrote for Upstream CIO's October issue (written in July '05). In rereading this article today, I surprised myself how aware I was of the forthcoming Cloud & SOA convergence.
The popularity of Service-Oriented Architecture (SOA) is gaining ground on the heels of the success of eXtensible Mark-up Language (XML) as a means for representing data in a technology-neutral manner and its ability to move data between applications. However, SOA plays a more important role than merely a moniker to capture the use of applications that communicate using XML. SOA is the software world's entry into the utility computing model.
For CIOs, the utility computing model has come to be synonymous with the ability to provision computing resources on demand, thus maximizing these resources based upon needs of the organization and its customers. In some cases, the utility computing model has begun to incorporate metering, which allows IT organizations to charge back usage to individual departments or projects, thus enabling the CIO to demonstrate the need for the current resources and to plan properly for capital expenditures of new resources.
Moving to a utility computing model helps organizations consolidate computing resources, which results in lower costs of ownership and management of those resources. However, due to today's inefficient software designs, most computing resources are dedicated to a single function, such as Web applications or enterprise resource planning. Such dedicated resource allocation means you cannot re-provision them to other tasks when the demand hits. Instead, IT departments are forced to acquire enough computing resources to satisfy each function running at 100%. This results in organizations overspending on computing resources to compensate for this limitation imposed by the software. Thus, today's application models are undermining consolidation efforts and limiting the cost savings to the organization.
Enter SOA, which offers a software architecture that maps more closely to the utility computing models that have already been adopted, allowing better allocation of resources and greater provisioning controls. SOA enables organizations to develop and, more importantly, deploy their software in a loosely coupled fashion. This means the software is designed as a set of black boxes that have well-defined inputs and outputs, such that they can be linked together in a process flow with ease.
SOA operates on the concept of service providers and consumers who have agreed upon service contracts. These contracts are based on well-defined messages that are passed between the provider and the consumer, but at an abstract level, they are no different than the agreements that you have with any other utility, such as the phone or electric company.Indeed, supporting these contracts requires the same service level agreements that would be expected of mission-critical utilities.
While there is no concrete definition of SOA today, the generally agreed-upon attributes of SOA include being:
- Based on technology-neutral standards, such as XML and Web Services;
- Self-describing through metadata files created using the Web Services Definition
Language (WSDL); - Discoverable through a URL mechanism, which means they use common Web
mechanics for implementation; - Stateless, which means they can easily be reused since they are not reliant upon
specific resources being dedicated to them while they are in use.
These attributes lead to the creation of software that can be provisioned and allocated to a resource on demand, keeping in line with the tenets of utility computing. Moreover, the concept of providing a service means that computing power can be made available like other utility-based services, such as telecommunications and electricity, which have the ability to direct more or less service based on need.
Hence, this change in architecture leads to a fundamental change in the way software is designed, but also in the way that software is deployed and managed. For example, once a service is developed, it needs to be deployed into an infrastructure that is operationally managed. This means the service may require access controls, redundancy, quality-of-service, service level agreements and root cause analysis when it is not available. These are the same services one would expect of any utility-based service.
In keeping with this model, then, SOA maps perfectly into existing utility models, such that IT can charge back infrastructure usage based on its existing utility metering, adding on charges for the number of times the service is invoked. Additionally, IT has more control over the resources used by these services, such that a single service will not require a significant allocation of a particular resource, such as today's application servers or SAP servers require.
Thus, the organization can deploy services where there are available resources that fit the demand for that service. Moreover, this change will not impact existing applications if they use the model of "find and bind" that has become a cornerstone of SOA. That is, users can look up the location of a service in a registry and dynamically bind to and use that service without any prior knowledge of its existence.
This movement toward SOA requires a fundamental shift in the way that IT operates within most organizations today regarding software. Today, most IT organizations follow a system integrator model of delivering software, which means they take existing off-the-shelf applications and/or programming tools and deliver an automated solution to a business problem, similar to the service provided by Accenture or BearingPoint.
The move to utility computing using SOA requires the IT organization to operate more like the electric or phone company for their organization. The IT department may still do development work, but it will mostly be responsible for creating new services. Eventually, business tools will create these services. Thus, IT will become the organization responsible for the infrastructure for provisioning resources for these services based on demand, with the goal of no interruption in service.
This is a major change for many IT organizations that are managing silos of applications today. If one application that supports fifty users is unavailable, IT can expect five to ten calls to the help desk. However, if a service that supports fifty applications is unresponsive, the help desk can expect to receive ten times that many calls. Needless to say, the impact of this paradigm change to the organization and the IT resources is significant from both a cost and resource perspective.
The utility computing model can save organizations millions of dollars each year
through hardware and human resource consolidation. By adopting SOA, organizations can incorporate a software model that easily maps onto the utility computing model, such that resources do not need to be dedicated to particular applications, but instead can be provisioned based on demand within the organization. This approach requires the organization to plan for changes in how the IT department operates and the types of skills required to build and support an effective utility computing model.
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.
Cloud Computing: New Stuff or Legacy Revisited?
There's a lot of information hitting the bitwaves touting the value of cloud computing and it seems that within the IT industry those that profess positive opinions of an emerging market during a hype cycle seem to get more attention than those with negative or pragmatic opinions on the issue. Thus, the hype cycle reinforces itself and the hype grows larger. With regard to Cloud Computing, I've commented before on the two leading opinion groupings--the Gray Hairs and the Newbies. The Gray Hairs look at Cloud Computing as time-sharing redux and the newbies look at it as the only way computing will be done within the next 20 years. Ho hum!
Let's look at what is the same about Cloud Computing:
1. Outsourced hosting - IaaS, HaaS, etc. are just fancy new ways to talk about a model that has been employed for many years now. Effectively, the Cloud provides an economic way to leverage shared computing resources for an economic benefit.
2. Hosted applications - SaaS is just a new way to talk about application service provider (ASP) model, which has been in operation since the 1960's.
3. Disaster Recovery - Even those that have built their own data centers often contract with companies that maintain the necessary hardware and operating systems to enable continuance of operations in the event of a disaster.
Now, let's look at what's new about Cloud Computing
1. Scale - due to the massive reduction in the costs of memory, storage and CPU, we can now offer unprecedented linear scaling.
2. New distributed computing architectures - projects like MapReduce and Hadoop leverage our ability to scale linearly and turn it into an ability to scale exponentially. Linear scale still suffers from an inability to have a 1:1 mapping between storage and memory, thus the speed to read a gigabyte of information limits many of the scaling benefits. Architectures like Hadoop and MapReduce parallelize the access to the data across multiple processors and multiple data stores dramatically reducing this limitation.
3. Virtualization - the ability to leverage a single machine architecture to host multiple operating systems changes the DR costs significantly. In many cases open systems DR costs can be cut by a 1/3 of what they costs prior to mainstream inexpensive virtualization and the development of the hypervisor.
4. Metering - in IT has typically driven by transactions or fixed fees, but, the Cloud treats resource usage like telecommunications industry treats data and voice by billing based on usage, which allows for more affordable pricing models
So, Cloud Computing takes advantage of some of the advances made in computing and combines it with ideas and business models that have been working for the past forty years.
If My SaaS Also Exposes an API, Am I Also A PaaS?
Here's a great example where an agreed-upon taxonomy of Cloud Computing terminology would really be helpful. Software-as-a-Service (SaaS) is fairly-well understood from both a business and delivery model perspective; that is, if we agree that SaaS is software hosted external to the user and billed on a usage basis versus a license basis. A typical SaaS application provides a user with a client to access the service and stores the user's data in the cloud. There are tons of examples of SaaS applications today, both billed and free models including Salesforce.com, Facebook and Google Applications.
However, if a SaaS application, which provides a user interface that a human can use to access the service, also provide an application programming interface (API), does it also qualify as Platform-as-a-Service? The typical PaaS offering has been focused on a coupling of discrete technologies that can be deployed as an integrated offering. It typically has an operating system, some frameworks, a runtime facility and runs completely in the cloud.
Some might also consider a common aspect of these platforms to be that they are deployed and managed as virtual machines and the applications produced on them to leverage elastic computing capabilities. In my opinion, this crosses many aspects of Cloud Computing, including Infrastructure-as-a-Service (IaaS). Thus, another indication that there is lack of agreement on the boundaries between many aspects of Cloud Computing.
However, let's return to our key focus; the border between SaaS and PaaS, and let's look at a well-known entity that meets this criteria—Facebook. Facebook is SaaS. The application manages your social connections and allows you to communicate with your community via text and pictures, both directly and broadcast. Each Facebook account is essentially a unique community with a distinct set of users and connections.
Facebook is also an application platform. The Facebook API allows developers to provide additional services to each of these individual communities. However, Facebook does not host this application. Instead the developer is required to host the application for themselves. Facebook provides a portal to access the new service, provides a facility to allow its community manager to control if the application has access or not and what levels of access are allowed. It also provides an interface to allow each application to connect into community features.
If I draw clear boundaries around PaaS, such that it represents only those offerings that can be deployed as a complete entity, and does not include offerings where the platform is already deployed and accessed via a service interface, then Facebook is not PaaS. However, this means that PaaS is once again a poorly-named IT offering, because, it is a platform and it is offered as a service.
I realize that I do not have a good answer for this conundrum as of this time. I believe the answer lies in semantics and taxonomy, but it is not something one individual can drive alone.
How To Define SOA and Cloud Computing
Everywhere there is a forum for individuals to communicate about Cloud Computing or SOA, whether it's a chat room, discussion board, LinkedIn Q&A, Twitter or Facebook, I notice a similar pattern forming. These terms, regardless of their origin, are continually being re-defined by the community-at-large, which has both positive and negative results. On the positive side, individuals are working together to try to figure what these terms mean to them, a very natural tendency in the face of ambiguity. On the negative side, there is considerable room for fear, uncertainty and doubt to be introduced.
With regard to SOA, I have played semantic cop to the mass hoard that did not want to all agree on a single definition. My attempts to use logic and humor to dissuade the masses from capitalizing on the term and minimizing its value seemed to have fallen on deaf ears. The same sequence of events is now occurring around Cloud Computing. There is definitely a lack of clarity about what Cloud Computing is and what it is not. Pundits are throwing their hat into the ring in an attempt to gain market share for their ideas. A great example of this is the "private cloud", which to me is like saying "the private Internet," which I believe was appropriately named the Intranet.
This has led me to realize that these terms are too big and too ambiguous to ever again be bound by one definition, which means they are now a classification. So, instead of trying to define them in a narrative manner, I believe we need to define them as a scheme with many components that are interrelated.
Disclaimer
My Most Recent Book
:Other Links
Web Profiles
Recent Posts
- Cloud Computing Pragmatics
- The Real Impact of IT Owning Your SOA Effort
- Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
- The Busy Executive’s Service Oriented Architecture Reference Guide
- The Busy Executive’s Quick Cloud Computing Reference Guide
Tags
Recent Comments
- Steve Hughes on Cloud Computing Pragmatics
- CloudSigma on Cloud Computing Pragmatics
- Is ‘Service-Oriented Approach’ a Better Way to Define SOA? | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service on Perhaps SOA is More Strategy Than Architecture
- Jaime Ramirez on The Busy Executive’s Quick Cloud Computing Reference Guide
- gon zalez on The Busy Executive’s Quick Cloud Computing Reference Guide
Blogroll
Other Links
Archives
- July 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- September 2008
- August 2008
- May 2008
- December 2007
- November 2006
- April 2005
