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 Real Impact of IT Owning Your SOA Effort
I had a great lunch discussion today regarding the impact of ownership of SOA within the business. As I have discussed multiple times, SOA is about business services, not technical services, but the reality of this point is lost in semantics. The following illustrates the different perspectives that each have and how that impacts the overall SOA initiative.
Let's look at two business capabilities in real estate: renting the building space (sales) and drawing up rental agreement (legal). Each of these business capabilities are effectively services to the business. In order to operate effectively, they need to share some basic data, such as property listings and renter information (CRM). They also operate synchronously as part of a business process that results in the execution of a rental of a property. Otherwise, they operate fairly autonomously from each other.
From the business' perspective, at a minimum, they'd like one and only one of each of these capabilities, each delivering in a consistent manner. Sometimes, that is not possible. Perhaps, there needs to be two distinct sales teams due to regulatory or licensing issues. In this case, the business will still want the multiple sales teams all operating in a consistent manner, using the same forms, if possible, and interacting with the legal department to draw up the contracts in a consistent manner. The consistency is what enables the business to operate efficiently even in the face of redundancy.
In this particular case, I believe, while not optimal, it is perfectly okay for there to be redundancy of certain information systems in the delivery of each of these business capabilities as long as it allows the business function to deliver consistently and efficiently. For example, if each of these groups had selected a different portal product to provide access to the property listings, that would be acceptable as long as they were operating off the same listings service. Forcing these groups to consolidate on a single portal product is not going to provide any additional efficiencies for these groups or simplify their ability to deliver.
However, what we see happening in the industry, is that SOA efforts are being led by IT and not by the business leaders. Hence, IT views the problem from a systems perspective and sees the need to remove redundancy at the information systems level. So, instead of focusing on business capabilities and making sure that the business rules, processes and goals are being executed consistently and that redundant business capabilities are consolidated, they look at the redundant portals and identify them as a target for consolidation, as so they should. ITs job is to keep IT costs down and are rewarded by simplifying the work of the IT department. However, as I used to remind my developers, it's not about what's easier to code, it's about making the jobs of the users easier, that's why they pay us.
The result of IT forcing consolidation of portal products is some cost savings, but interruption and change for the business. The overall productivity losses within the business function due to the interruption is typically never identified, let alone measured. Users will need to be re-trained on the new portal, things won't work initially and users will become frustrated and be less productive. All of this for the possibility of reducing the costs of managing one additional piece of software.
I say let sleeping dogs lie. There are plenty of real information management costs in most businesses that eliminating will offer a real benefit to the business' bottom line. Clearly, both of the aforementioned business capabilities need to be operating off the same customer and listing data. There's plenty of work to be done by IT without focusing on needless change. Eliminating the additional software licensing costs are penny-wise, pound foolish when the real impact is analyzed and assessed.
With regard to SOA, IT will view SOA as an IT effort that results in consolidation of technical capabilities. That's their task and that's how they are rewarded. IT is not rewarded for improving productivity in payroll by improving the end of month process. And, therein lies the flaw in the system. We have become heavily reliant upon our data and applications to run our business, and therefore, IT has become a critical function of the business. Yet, the business world rewards IT for running with as low of an overhead that can be comfortably be achieved without putting the business at significant risk. If we really expect SOA to live up to its promise, it is going to have to become an effort that is undertaken by the line of business as they reorganize for streamlined operations, or, if we're going to let IT own the SOA, then we are going to have reward IT for improving productivity and usability of the systems in a manner that is best for the users and not necessarily IT. That is, we're going to have to let them focus on actually aligning the information systems with the needs of the business and not force the business to live with the limitations of the systems.
Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
Thanks to @jadkins for the colorful ending to that cliched saying, which really got me thinking. Sometimes we just make certain aspects of architecture too difficult for no reason. Good design is important and can have significant financial impact if done incorrectly, but chances are the negative impact comes into play during the engineering effort, not during the architecture. To clarify my point, one must first understand what architecture is really focused on and how that differentiates from engineering.
For example, if we're designing a solution for financial services products. I can choose to take a framework approach to architecture in which we identify the common financial services components, such as securities and instruments and expose the manipulation of these components through the framework. Then we can continually add new algorithms to manipulate these same components in a modular fashion. Yet, another approach might be to examine things from the perspective of the buyer and the seller and allow each financial product to implement it's own representation of securities and instruments and orchestrate the process of selling and buying.
Either of the aforementioned scenarios is a viable architecture. In the former scenario, we can develop new computational models very quickly as long as we don't change the definition of the semantic elements. However, it can be a bit rigid since all new products must be able to define the components of its product based on these definitions. Also, sharing these products across trading partners becomes more complex.
In the latter scenario, we have a more service-oriented approach, focusing on the consumers and less on the definition of the products themselves. Hence, each service is unique, and may produce redundancy in defining the elements used to create a product, but we can orchestrate buying and selling across products in a common fashion. This approach facilitates incorporation of a much wider community since agreement is not required for the representation of elements to create a new derivatives product.
Which architectural approach is better? Well, as any good consultant will tell you it depends on your goals. If your goal is to allow your big brains to develop new models quickly to identify market making opportunities, then the first approach sounds ideal. If your goal is to enable a new derivative product to be treated as a single instrument even though it's comprised of securities that are bought and sold across a variety of exchanges, then the latter approach will probably suit your needs better than the former.
Neither scenario is optimal or guaranteed, but they both represent a means of simplifying the system enough to extend it over time without considerable re-work efforts.
When complete a design goes through an engineering effort where a software engineer will take this design and "press" it into software. During this effort, decisions are made about platform, programming language, external libraries, software development methodology, etc. Any one of these decisions, or a combination of them, may lead to the undoing of the great abstract architecture designed. For example, if the system cannot scale to the volume of financial services transactions, then that would be one major flaw. Using an open source library that ends up having a major security flaw is another potential flaw.
These scenarios are not very different than design and engineering in any other industry. The architects can design the most awesome car or impressive building, but if the engineers select the wrong parts or use inferior materials, the resulting product will never allow the architecture's brilliance to shine through. Note, manufacturers put significant effort into ensuring that their designs will work by building prototypes and testing against known environments that the product will have to operate under. Thus, from this perspective, architecture is responsible for putting forth a design that is credible before engineering commences.
The Busy Executive’s Service Oriented Architecture Reference Guide
Based on feedback from my last blog entry, "The Busy Executive's Quick Cloud Computing Reference Guide" the consensus was that people found it very helpful as a means of gaining quick understanding of what Cloud Computing is without getting mired in heaps of technology jargon and hype. So, I decided that SOA needed something very similar. After all, there's so much confusion and misunderstanding of SOA in the market right now.
Let's start with a basic understanding of a service. There are lots of things that you can call services, which is where many of the problems arise for SOA. I believe that the use of the word service in context of "Service Oriented Architecture" connotes a particular meaning that filters out most of non-applicable definitions of services. To further illustrate this meaning, I will discuss services in the context of software services so as to clarify the differences between SOA and not-SOA.
First, SOA is an architectural approach designed to identify and delineate business functional boundaries within a particular domain. A domain can be a single organizational unit or an entire industry. Regardless of the domain, if there are interactions within the domain, then there is most likely more than one unique business functions used to complete those interactions.
Many times, and more often with larger domains, there is more than one way to accomplish a particular task or objective. When a domain is required to support multiple paths to a singular end, it has been identified that the redundancy has an associated cost. Removing that redundancy results in efficiencies and cost savings. Very simply, SOA is the initiative designed around identifying the domain goal, marking the necessary business functions boundaries required to reach that goal, consolidating these business functions so that there is no redundancy and then orchestrating the process to reach the goal against the resulting set of business functions. The identified business functions are your services. Note, without these business functions you cannot complete your mission and achieve your task.
Most people agree on the following regarding desirable attributes of a service. We use them to do work for us that we don't want to do, we want them to be consistent and reliable, we want to pay a fair price to use them and we don't want to own them, and we don't expect to still be responsible for part of the job after hiring the service. If you hired a landscape service for your house that was supposed to prune your shrubs and you still had to go out on the weekends and clip the hedges, chances are you'd fire that service provider.
All the "chatter" in the media and on the Internet would have you believe SOA is very complex and requires expensive software and expensive resources when all we're doing is looking at a particular domain and figuring out how we can chop it up into a group of services that work together. For example, a landscape service and a mulching service have particularly good synergy, would you agree? These are two distinct services, but they have what we call a loosely-coupled relationship. That is, they work together for the duration of a task and then go their separate ways.
Granted, the task of looking at a domain and breaking it down into a set of services is a strategic skill that requires an experienced practitioner, but formulating the boundaries and putting the governance around those boundaries in place can be done by current management.
Now that we have these critical elements defined, let's compare three different topics of software that have all been associated or labeled SOA. Of the three, only one is truly SOA. These three topics are: Software-as-a-Service (SaaS), component-based software development and real SOA.
Why Isn't Software-as-a-Service a Service? To answer this, let's return to our agreed upon attributes of a service. SaaS meets one criteria we defined for a service—we want to pay a fair price to use them and we don't want to own them. However, most SaaS is just rented software. You're still responsible for integrating your data with the SaaS application after you rent it. You're still responsible for configuration of the forms and workflows after you rent it. For me, SaaS fails to meet the other key attributes of a service.
When many technologists and IT specialists discuss SOA, what they most often really mean is component-based software development. Many people in the IT industry have used the label SOA to describe a way to build software systems. This is possible, if the software represents critical business functions as we will explore shortly in the discussion of real SOA. However, in these conversations you will also hear things like SOA platforms and utility services. These are sure-fire indicators that the discussion has degraded into software design methodology and has left the realm of SOA.
Here's why there's no such thing as a "utility" service and it's just a software component. If the business itself would be less scalable or cease operation because the service is not available, then you have a service. If the mulching service doesn't show up when the landscaper is there, the landscaper cannot complete their task. Whereas, the utility service concept is a technological artifact of a software or solution design. The software providing the business service could exist without the existence of the utility service. The resulting solution may not be as modular of a design and, perhaps, not offer the service provider, the preferred level of agility and flexibility, but the service consumer would be no worse off than if you decided not to build a utility service, but instead, developed that business logic directly in to the software itself.
The last topic is SOA and real services that are comprised of software. The best way to describe this is to look at a couple examples of services that I have developed over the years.
The Alert Service – This is a software-based service that was used in data center management to notify personnel that a problem had occurred. A user or another piece of software could create an alert and it would send the notification via a number of mediums, such as pager, fax, phone, email and printed ticket. This software took care of the entire task, didn't have to be built for each individual usage and delivered the one and only one way to perform the task goal.
Zero Bond Calculator Service – This is a software-based service that provided various zero-coupon traders with a consistent means of quoting a zero coupon price. The service happened to be accessible via Excel, but could have been offered via phone or other mediums if necessary. The trader provided the inputs and the calculator service provided the pricing. It consolidated the various approaches to pricing used by each different trader, thus minimizing the overhead of the trading desk. Again, it took care of the entire task, didn't have to be built for each individual usage and delivered the one and only one way to perform the task goal.
In each of the aforementioned examples, the software represents a business function that was implemented using software because it was easily automated and reduced the need for human labor. However, because it was implemented in software, does not, in and of itself, make these services. It's the role they represent. These services allowed the business to reduce complexity, consolidate around one way of achieving a goal and do so in a way that was agile and flexible. Moreover, while they are not dependent upon one another to provide value to the business, one could easily see how they could work together synergistically to ensure high-availability of the zero coupon pricing calculator for traders.
That's SOA in a nutshell! Identify, consolidate, orchestrate and govern a set of business functions or capabilities.
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.
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.
Blogging Is My Civic Duty
Why do I blog?
For me it's a civic duty. I have an ability to identify the real value of IT investments and directions to business. There's a lot of noise out there coming from sources with their own agendas, both internal and external to an organization, that makes it difficult to fully understand the long term impact of any IT decision.
Overall, most IT failures have been washed away in short time spans, perhaps the IT leader suffered a political death in the organization, if not downright asked to leave, but overall the business does not abandon the solutions that are working, even if they are not working effectively. However, these continual failures do have an aggregate effect in wearing away confidence, which has an overall negative effect on the industry in which I make my living. As more business leaders lose faith that IT can be used to directly help them, the less inclined they are to spend and grow this industry.
I view my content as putting out some filters into the system to balance the noise. We all have an agenda, and mine is to improve the quality of information available to business decision makers regarding emerging directions in IT. However, my agenda is not self-serving with the exception of improving the entire community, thus, my information should be deemed trustworthy. Moreover, my blog, articles and community discussion input provide real discussion and enhance the overall quality of the conversation around these topics, which delivers greater value than reading a vendor-sponsored white paper.
The realities of the situation is this, executive business leaders need a system of checks and balances for IT acquisitions within their own organization. 99.999% of people attempt to forward their own agendas. Sometimes, those are aligned with the mission and sometimes they are not. Projects that are the equivalent of the "hail mary" play in the final seconds of the game to win, or promote oneself as the hero of the day, often end up being dropped passes that waste precious time and money. If I was a CEO or CFO that was not technically savvy, I'd make sure I had an advisor that could assess and provide objective feedback on the direction and decisions of IT management, which, by the way, is a great role for an Enterprise Architect.
My agenda is simple, improve the quality and reliability of solutions being provided by the IT industry as a whole. To make sure that IT decisions are vetted for economic feasibility and provide real value toward the mission of the organization. And, most of all, to raise the overall confidence of business in investing long-term IT investments that ensure continuity of the business in a world of growing uncertainty. While we cannot know what will happen tomorrow, we do have the ability to lay a foundation that will allow faster response to changes as they occur. Moreover, this goes beyond pure software, but the way we deliver IT as a service in general.
Desperately Seeking SOA Business Cases
The follow question was recently passed along to me by a peer:
"…There seems to be anecdotal evidence that moving a system to SOA, or creating a new system using that architecture is the right way to go but she was looking for something with numbers of metrics that she could use for her boss…"
This is a really important question because I believe that the person seeking this information is not alone in attempting to identify real value of investing in Service Oriented Architecture (SOA). The problem is that a properly done SOA should be unique to the mission, goals and processes of the organization making it of limited relative use to another organization. That is, SOA offers a framework for identifying, isolating, delivering and servicing a consumer need, and, while all businesses have some common aspects, the resulting business services should be unique to the needs of that business' consumers.
So, what then is the real value proposition for SOA? The answer to this question is the age-old consulting answer, "it depends!"
For one thing, SOA is so poorly-defined that just about any IT project can be labeled SOA, which means that anything you want to place an SOA label on that enhances productivity, reduces costs, increases profitability or otherwise has delivered value to your business. One of the yardsticks I use to measure an SOA by is that the effort has produced "product"—by product I mean a tangible and achievable asset has been defined—that consolidates execution of a business function within the business in one of two ways; a) a consistent process that may be replicated but is executed identically, or b) the function is executed by a single unit within the business. Note, in some discussion of SOA you may see this represented as a requirement for reuse, but reuse is not our goal as reuse implies a choice to use or not use. We are seeking consistency and, what I call the need to have something built once-and-only-once, ergo, no choice; the service must be designed in a way to support its consumer audience completely.
In (a) above, it's important to remain flexible in design. Some businesses are designed around their customer need, which means that a business function may need to be replicated due to privacy or confidentiality concerns. However, that does not mean that, where replicated, the function should not follow a consistent approach. The benefits and value of this to the business are significant. It allows employees to more easily be moved around, it reduces the costs associated with downstream processing and it simplifies the operations of the business for planning purposes. With regard to (b) above, that's fairly self-explanatory. By consolidating multiple, different approaches to delivering the same business function within the organization, e.g. receivables handling, it will result in lower expenses and overhead.
I believe the key take away from this blog entry is that you can explore how others have succeeded in applying the steps I have outlined above, but you will need to seriously consider what it will take for your organization to leverage SOA design concepts to deliver value to your business. Moreover, the first decision you need to make is what improvements or value propositions matter most to your business, and NOT what SOA metrics exist to justify moving in that direction. Or, to rephrase that famous Kennedy quote, "ask not what SOA can do for you, but ask what you can do to improve your business!"
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
