Demographics & Computing

It has not slipped my attention that the most valuable companies in technology industry today tend to be culturally oriented (Goog, Apple, RIMM etc). Sometimes also called consumer oriented technology. Contrast this to the most valuable companies of the 90s which were infrastructure oriented. One could justify this trend to reasoning derived from study of economic business cycle which says first there is overinvestment in a trend followed by bust and painful restructuring and another (and longer) boom. Analogies are drawn between railroad construction bubble followed by bust followed by boom. Using this reasoning, the internet industry should have restructured and the next killer application should have been business oriented. Instead what we seeing is the killer application for the internet is "Cultural Networking".

I think the driver is shifting demographics in the world. Rutgers university did some research on the demographics in US, specifically, of people between 18-25 years of age. The research calls this group the "Millenials". SF Chronical earlier this year published a story on this group and their economic behavior. Interesting tidbit from the article is that this generation (approx 70M in strength) is just as large as the boomers (77M) generation. Lot of research has shown that rise of consumption driven economics in the US was due to boomer's purchasing habits. Today, it is these millenials who are driving the consumer economy, I think.

This explains the increasing adoption of electronics networks (on internet) to communicate, form opinion on product and purchase of the same.

Web 2.0 Infrastructure

In one week, I heard the two major networking companies's CEO mention Web 2.0 and SOA - trends normally associated with computing. What makes these digital plumbing companies interested in Web 2.0 and SOA?

As I have been blogging now for the last 4 years, it is all about converting a compute problem into a networking problem. These two trends shift the focus of innovation away from shared APIs and data adaptation which was the focus of the integration business to standards based networking of application components.

The networking companies who so far been content with connecting stateful compute devices now have to start figuring out how to connect a stateless compute device with its state which could be resident anywhere on the network. In other words, they have to move beyond "Can you hear me now?" to "I can be there now (digitally at least)!"

This is going to require a major shift in thinking (and later business model) for networking companies. The CEOs of the networking companies realize this and know that to stay relevant they need to understand the intelligence that resides at the end nodes and how they can serve the communication needs of this increasingly distributed intelligence.

On the other side the computing players who gave birth to SOA and Web 2.0 have to learn how to use the network. Specifically how to overlay the intelligence that they now control on to a network. Doing SOA on a compute platform is DOA. Doing SOA on the network is the future.

Industry Is Climbing a Layer of Abstraction

Where ever you look in the industry, there is a new trend that is driving research and development of the next step in the ladder of abstraction in computer science. You only have to scratch the surface of household buzzwords like SOA, Web 2.0, Grid Computing, Virtualization, On-Demand, Utility Computing and (of course) Application Overlay Networks or AONs to realize that these trends are nothing more than a layer of abstraction over everything that is being done today.

Start with SOA, it is a layer of abstraction on top of currently dominant programming paradigms. At this new layer, one has to independent of Language, the underlying hosting environment, the underlying data model and inter and intra application communication protocol. You are seeing XML driven data models take hold on top of a hosting environment that is supports platform independent interfaces and the interfaces themselves are described in a platform and language independent fashion.

Look at Web 2.0 abstracts the web tooling to a level where the underlying platform becomes the whole internet and not just a datacenter. The run-time of this new trend is a catalog of web services that are exposed on the internet and the client side hosting environment is the browser. Most of the problems in this space actually has to do with the fact that the network programming is still stuck at the socket level of abstraction.

Grid Computing abstracts a unit of computation to a new level where it is totally independent of underlying CPU and IO architecture. Its cousing utility computing tries to do the same on the economics of computing by trying to find a pricing model that actually correlates a customer's SLA with his/her use of the underlying infrastructure.

Virtualization and On-Demand who can claim to be the progenitors of all the subsequent abstraction trends (and actually the only ones making money) aim to abstract into software all the necessary and sufficient characteristics of the underlying hardware. On-Demand actually focusses more on management.

Finally, coming to AONs, this is the new abstraction layer at which tomorrow's network needs to operate at . The article on "The New Network Switch" does a good job of summarizing the AONs which is what Sun's xCEO referred to as the "Big Freakin Web Tone Switch".

Ubiquitous Purchase Order

If you ever get into a conversation which discusses use cases of SOA, then you have probably heard of the Purchase Order (PO). The use case goes something like this, there is a PO which needs to be routed across multiple enterprise components (recently exposed as web services) and this PO needs to find its way to its destination through a maze of business processes. It seems every one has a policy which says "if the PO is greater than some dollars then send it to big boss otherwise the little guy can do it as well".

So abstracting the use case out a bit, we are saying the PO is the input into a black box and some processing occurs and the PO changes the state of the black box and returns a zero or more messages saying so to the originator.

I have yet to hear someone question this use case in context of the vision of SOA enabled datacenter. I always wonder why the PO even has to even exist. After all in the world of SOA, multiple systems are now connected at the application level and supposedly understand the business processes extant in the organization.

POs were created because the buyer and seller had no other way to account for a transaction. PO was the document that implemented the approval process, the actual transaction and the budgeting process. If the underlying IT infrastructure is moving towards loose coupling, the overlaying business processes would need to be reengineered to take advantage of this new infrastructure.

I think the biggest opportunity in SOA might end up in the laps of management consultants. Perhaps, I should have stayed at Booz.Allen ;)

SOA Patterns and AON Appliances

There is a lot of discussion around SOA patterns now-a-days. If you have used patterns in your past life, these SOA patterns are not really the same thing. It is not a reusable chunk of code that you can cut & paste. These are big chunks of functionality that needs to be deployed at various points in your network. From an AON perspective, almost every pattern in SOA can become an independent appliance on the network.

When the first appliances hit the market in 1997 timeframe, the pattern they followed was Linux + some server. An AON appliance is a dual plane appliance which has XML for data plane and a control plane which depending upon the pattern that the AON appliance is implementing can be Java or a scripting language or anything else. The performance of course comes from the data plane.

So if we survey the SOA landscape today, we can easily find references to Gateway Pattern, Governance Pattern, Broker Pattern, Router Pattern etc. Each one of these can be made into an appliance in a service oriented network. The only difference between the appliances would be the control plane. You could deploy all these patterns into a collective which some folks call the ESB or you could drop-in appliances at various points in the network to achieve the same result.

Once you have the patterns deployed the challenge shifts to managing the multiple deployed patterns, plan for capacity, scale it and secure it etc. This is where a network based approach with appliances shows its clear advantage. Capacity planning, securing, scaling, sharing etc. are networking's forte.

AON Device Programming

The fireside chat from a Cisco executive on SONA addresses a FAQ on AON devices's programming environment. If you have the time, I assure you this 1 hr+ presentation is worth the time.

As the presenter points out, AON devices are not programmed in the same way as the server side cousins. There is no IDE, SDK or APIs. The fundamental task of an AON device is to find the destination service and route the message to that service and perform any intermediary tasks that can be in done in the network. This message path is programmed rather differently than a server side implementation. For example, a message path which simply accepts a message from a synchronous http channel and dispatches that message to an SMTP channel would look like this.

[from-http-sync]
Match => "SomePatternInAnyGrammar", WithThisPriority#, RunSomeProcessing
Catch => "ForTheSamePattern", ThisException, RunThisExceptionHandler
Include => SomeOtherContext, WithTheseConditions
Dispatch (TransformedMessage, OnThisChannel)

These simple context can be combined to form a larger context which defines the message path. On the CLI one can easily verify that this rule is turned on by

CLI> show context from-http-sync
[from-http-sync created by ...]
'Pattern'
1. SomeProcessing
2. Included Processing steps of another context
3. Dispatch to SMTP