Who killed Blockchain?

We have all been to a notary to complete a transaction or an application for important events in our lives. The general procedure involves one signing/dating the document followed by a signature/stamp from the notary. The notary also makes a entry into his/her ledger. The purpose of the ledger to some time in the future validate the notarization. Now what if we had a technology that automagically places all the millions of entries across hundreds of thousands of notaries into a access controlled ledger on the internet? That would enable notarization by any citizen, entity not in the bad books of society. It would enable cross border notarization (read trade). Extend this use case further and you could apply this technology to validate your credentials, your deeds on your assets, your birth/death/marriage records. This technology would fundamentally change the way humans are organized today.Everybody agrees it would be great to have this technology flourish, but alas I read it obituary everyday.

To understand why, I would invite you to watch the movie who killed the electric car? There is something in the movie for both bulls and bears of blockchain. The bulls will say but wait.. EVs are not dead and so there is hope for blockchain. Bears will say, but those tactics (like filing patents and locking up competitive innovation) worked as it delayed the  EV for several decades. (My own first experience with EV was Sun's Java car in 1999). I think blockchain is going through one of those moments where the ones whose empires will fall ("trusted intermediaries") first joined the party and then played party pooper.

Elephant in the Datacenter

I hear conversations at eateries discussing virtual wires to move packets between software endpoints. I believe the problem of moving  packets or making a remote procedural call  (across administrative domains) is already solved. What is not solved is the policy around the movement and invocations. We need to solve this problem if we are to tackle the elephant in the room.  When I listen to end users of technology, their discuss their pressing problem and that is phishing, robocalls, invasion of privacy and at extreme fear of constant surveillance because of AI. The intrusion they are concerned about is not from rogue states but rogue software that runs within our trusted perimeter. This is not going to be solved at the lower levels of the compute stack. This needs a Layer 8 security solution whose enforcement takes place at all seven (or five) layers below.

I spent the last year trying to understand the appeal of blockchain as a data structure and now I am convinced that is how we should look at blockchain. It is a data structure like a class in Java or struct in C. We should use it when we want to store data with access permissions of the owner of the data. When that happens, we will be uploading our photos and storing our documents with a checkbox which says private and that would cause the platform's software to store the datum in a blockchain that is personal to the person who uploads. It is like a vault in the bank where not even the banker can access the contents without your private key.

This massive misallocation of capital to copy cat ideas only happened because of ridiculously low  cost of money. In a rising rate environment, hopefully we will see capital being allocated on issues to which society is waiting for resolution.

Happy Holidays

(Lack of) Trust is killing the World

Not to take on the "Software is eating the world" meme, I believe the pendulum has swung too far in the SD* world.

Automation was the killer app driving the softwarize everything and give it internal guidance (read ML, AI etc.), but at the end of the day it ended up being a great tool for the bad actors who used the automation to conduct fraud, invade privacy and outright steal. Think of an airport with no security where airlines automate all ticketing, boarding, everything. Not a very secure flight is it? The biggest threat to efficiency/automation/AI is fraud, malice and hmm . bad actors or humans.

What we need now is to build a platform that promotes trust not just communication. I went to engineering school when having an email was a privilege given to certain university students. Today I can communicate with my family over four different chat programs. They all use different ones. Do we really need this? Given all these choices, I still could not locate the person who sold me stuff on eBay that never arrived. What's the point?

If software wants to run stuff, the it should be accountable. Is should be trusted. Currently, the only technology that straddles tech and human boundary is Blockchain. These large platform companies should store all PII on Blockchain which should be under the user's control. My digital recognitions from University diplomas to Employee of the Day award should be on my personal chain. When we get to a point where I get alerted for when someone or something (read SW) is accessing my data using my public key on any platform or within any organization, only then will people trust these newly classified communication services companies. Until then, I think SD* will be put on hold. Enough of efficiency, I just want my privacy back!

Pets and Cattle

Any pet owner will understand the pain felt by the owner of the pet that died on United Airlines. What essentially happened is that flight attendant dealt with the pets as if it were cattle. Your onboard baggage is cattle and the airline is optimized for cattle. This is not a note on UAL or pets, but on the notion in cloud computing that enterprise applications are pets and should be converted to cattle so they can leverage the cloud computing infrastructure.

The market for enterprise software is around $280B and market for infrastructure that includes servers, network and storage is roughly $60B, $40B and $20B. As cloud takes a large upfront cost hit on the infrastructure they want to host workloads that are more sticky that the ones that drive revenues today. Today's workloads are mostly transient. New workloads start on the cloud and migrate out of it as soon as they are viable (business modelwise). So, it is understandable that cloud computing giants are pushing the pets vs. cattle metaphor and exhorting enterprise IT to migrate to their pet applications to the cloud. And why not, the prize is huge. Almost $200B of revenues should it happen. But will it? The case of UAL and the pet reminds us that pets cannot be treated as cattle and when they are the consequences are disastrous.

As any pet parent knows planning a vacation requires careful selection of pet friendly hotels, airlines and destinations. We don't have the same pet friendliness in a cloud yet. Given the economics of the cloud, it will be difficult.

Too many Dashboards

It seems we have a dashboard for every metric and dashboards to pick dashboards. This reminds of the early 2000s when widgets were introduced and we placed a widget for every metric, data stream on the desktop. We have distributed our IT systems and that enables us to monitor everything, but dashboard is not the answer. In fact with so many dashboards I kind of miss the good old monolithic system :)

What we need is an automaton which processes these metrics and takes automatic decisions. Dashboard seems too much like a business process. What would be great is if we get a alert saying "metric reached threshold and controller took some action".. kind of like what we get from our banks when a charge is made or fraud prevented. What would be neat is if we replace a whole bunch of dashboards with a few controllers that execute some policy that was recommended real-time by ML.

One horse or 10K Chickens?

Would you like to ride a carriage pulled by 10K chickens or single horse? The answer is not easy. It is technically cool to distribute a job over many compute units and when done successfully it replaces the workload on a more hospitable economic curve (cheaper, faster, better..). However, not all jobs can be distributed and a complicated system which does distribute it over cheap compute units ends up being so complicated that focus shifts from the job to managing this system.

We just spent over 6 mos trying to distribute a webApp and came to the conclusion that it is not about the app but about the data. We need to distribute the data and have compute thread scheduled on the data. But wasn't that the whole point of OOP?

Anyways, the search for distribution introduced me to blockchain. Here is a distributed network that kind of mimics human networks. It keeps people honest and has potential. stay tuned...

Network Data Analytics for Recommendation Tool

Yeah so first Happy New Year




Can analytics data collected from the network actually be used for driving IT infrastructure sales? This is what I was thinking about when scuba diving on the coral reefs over the break. As an aside I try to think of something pleasant when scuba diving as I tend to panic and hit the button to rise to the surface.


So back to the question. The answer IMHO is 'yes'. If we collect the right telemetry of an application distributed in the datacenter, we can answer a query like "What resources (IT) are used to create this latency profile". For example, if we know that a certain install of SharePoint has a distribution of response times that are satisfactory to the administrator then a simple query like the above should give us a list of inventory that made this possible. This inventory can include switches, servers, storage software etc. Evolve this tool further and this product can also give you TCO of a infrastructure by recording this data overtime and using it for TCO calculation. Telemetry needs to meet AI/ML for this to happen.


So the question is why isn't anyone doing this?

Developer will own Security Operations

I have a sneaky feeling that in coming year, the developer will strike big and get operational control of security in a datacenter and enterprise as a whole. Earlier this year, I warned that this should not  happen. Read This.


But I feel now, it is too late. Here is why. We have moved from securing perimeter to interfaces and now are talking about process jails. Some folks call it micro segmentation moving to nano segmentation.  From a ops person POV this means several orders of magnitude increase in number of endpoints that he has to identify and operationalize. i.e. he cannot do it. It will have to be done by software. And the developer owns software.


Yup, software is eating the world. It just ate the security ops.

Spark - Yup it is still all bout APIs

Having spent over 6 months now reading and practicing with code snippets on the big data ecosystem, the epiphany came to me that all I was doing was learning a new API. In fact, I was learning three new APIs: RDD, DataFrame and DataSet. It wasn't so obvious when I started reading about Apache spark. See the beauty of APIs is that it speaks the language of a developer and as a developer at heart and training I can easily understand what is being said.

All the stuff I had to read to get to this epiphany about Scale, R, NumPy and in-memory databases, keeping data in CPU registers and not in L1/L2 cache was just all confusion that kept me to from getting to the core. It took six months to weed through so much garbaget to get here.

Ok, so these three APIs help you deal with data. And depending upon the data, you pick one of these. The more structured your data the more you think of datasets and dataframes over simple RDD. And that is all there is to it.

Machine Learning, Deep Learning and Streaming Data Processors

When AlphaGo beat the human last week using ML to process a small set of board positions which its computing power could process, it proved that Deep Learning ML (that which uses algorithms vs. simply data) has arrived. But can the same machine analyze a streaming set of unrelated mouse clicks to identify a "hack"? Could it have blocked the hacking of NY Fed and saved Bangladesh $100M of lost funds?

As I refresh my understanding of ML - this time with Spark MLLib. I am thinking that this use case of streaming data analyzes with ML or Deep Learning is the NBT (Next Big Thing). To run this type of computational jobs, one requires a cloud because no small cluster will do and it needs a special fabric of the network because nothing enforces better than a policy on the network. Next generation compute systems and specially memory/microprocessor arch has found its killer app in streaming data processing just like GPUs found video games. This time the games are played by hackers and loss is measured in hundreds of millions.  

Microservices and Container - Not perfect together

There is a continuous turf battle going on since 1990s between developer and deployer (a.k.a Admin). Currently the admin controls the security, scale and size of the application. The developer controls the content, architecture and interfaces to other systems. Two new emerging technologies empower (or shift power) these two constituencies. Microservices empower the developer while container empowers the deployer/admin.

If either wants to take off, they need to find other partners not each other. If microservices want to take off it needs to get the container monkey off its back. It shifts the responsibility of security and scale on the developer and away from the deployer. Developer should ideally be limited to interface design and selection of abstractions that make logic easy to codify. If the security and scale fall in the hands of developer it is going against the grain of the evolution of application where binding is done as late as possible and certainly not at design time. A datacenter administrator will be very uneasy deploying applications where developer has coded in the security policy and scale limit.  

Container has a similar story. Container is not a disruptive technology like it is portrayed to be nor is its effect as tectonic as virtualization or  Java/JVM. It needs to find a partner in a deployment technology like a vagrant or rails or PaaS. Currently its main value proposition is the time to bring up a execution environment. But to get that one has to give up security, naming, directory and identity. In other words, what it is doing is pushing those decisions to the developer who is the most ill equipped to handle those.  

JESOA

In continuing my education on Microservices, I came across a blog which gave a formula for SOA. In essence the formula says remove ESB, SOAP, Persistence (Reliable Messaging) and centralized governance and add containers  + PaaS. That is the microservices definition.

There was a initiative a while back called JEOS for "Just enough Operating System". May be we should try that for Microservices equation as a function of SOA. It is just enough SOA.

Microsoervices

In trying to understand the difference between Microservices and Web Services (Circa 2002), I cam across this definition.

"..., the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." source: M Fowler


When web services started a similar definition was put forth. The main focus then was to get away from Java RMI into a light weight HTTP based communication and bring in language independence (then championed by Microsoft's CLR). As we implemented web services it became quite obvious that HTTP was quite heavy weight and language independence was not very economical. In fact what worked was language homogeneity with standardization on language that could shed weight for simple tasks and leverage a framework for heavy lifting. 

One of the biggest innovations in Java was the built in packaging and (later) deployment mechanisms. In fact most of the appeal of Java was in its "platform" features and not language features. This whole CNA biz smells a lot like language once again taking control of deployment and not leaving it to operations. We are seeing a application ops profession asserting itself. 

IoT is a Cloud Network

Cloud Native, SDN and SOA are all techniques not technologies. IoT is not a technique it is a use case that needs to use the above mentioned techniques to enable a mesh of connections that is manageable, secure and most of all just works. IoT could use any infrastructure including the carrier network but it is most likely end up using the cloud as a IaaS. IoT is a cloud networking problem that needs some connectivity middleware to sit on top of a virtual network. IoT is an application designed using SOA that will provision its network using SDN and will use ephemeral compute threads that have preexisting binding to the language runtimes. 

sdn and CMS

Only a few years ago, datacenter architects picked their overlay tunnel technology and created a list of stacks with which to build out their datacenter network. The cloud management system or even "the cloud" was an after thought. Today the tables have turned. We have datacenter architects debating the merits of various CMSes like OpenStack, vVMware (vSphere, vCAC, NSX) and a very distant third or fifth CloudStack. Within their CMS they are asking for support from one or more SDN stacks. The days of stanalone SDN stacks are gone. The battle today is between an open ecosystem like OpenStack vs. multiple closed ecosystems.

So what are the SDN stacks being evaluated on by these cloud datacenters?

First is ability to scale. And by scale, I don't mean just the overcoming the vlan exhaustion issue with annoating BGP or encapsulating L2 in L3 etc. Scale means the performance of the cloud network scales with the number of nodes in the datacenter. The nodes are server nodes. The cloud network does not scale with number of switches. Scale means your automation system can manage the configuration of a 50 node cloud as easily as 5K node cloud.

Second is heterogeneity. This one is a quite a beast because it requires supporting all the major hypervisors, authentication systems, SIAMs,  best of breed appliance (virtual and physical). From a cloud vendor's perspective this is where the R&D dollars are mostly spent i.e. in creation of a heterogenous ecosystem. Not proprietary ones like iCloud.

Third is security. Not just network security, or long expensive compliance test but application data input validation, fraud prevention, almost waf like.

Killer App for Overlay Networking/SDN

SDN has been searching for a killer app since its birth in the midst of protocol and encapsulation debates of 2011. It wasn't monitoring, flow management or physical network orchestration for a controller. It turns out it is container networking.

Container is challenging the VM or a group of them is a unit of application. Its value proposition is removal of the virtualization tax and being open source it does not cost a whole lot to try out. The schedulers (k8, mesos etc.) seem to be maturing fast enough but the networking behind is still quite elementary.

Using offloads that accelerate encap/decap of an overlay network on the JEOS (Just enough OS), containers with virtual interfaces can outperform hypervisor based VMs and integrate better with orchestration technology like gubernetes.

Utility Pricing in Cloud

The license management technology is still behind the times when it comes to cloud deployment. Most of the license enforcement mechanisms are based on hostname, ip address, usernames and are licensed based on seats.

There is pretty much no utility based pricing anywhere in the cloud. Either it is a flat subscription or a host based or site based license. If we want to regulate the internet as a utility, we need to figure out a way to charge the user for software used as a utility. There is nothing that I can see inside software system that even meters usage. Without this there is no way to bill a user based on usage. A utility based smartmeter for software is something that the industry needs if cloud biz model is to take off.

SDN and SmartNIC

SDN or programmable network is quickly being split into three separate problems. First is programmable management plane, second is programmable control plane and programmable data plane. A lot of time is spent on discussion of programmable management and control. But very little time is spent on programmable data plane.

Whatever overlay (over L2 or L3) is used for multi-tenancy, unless all the tenants are in the same host, the packet needs to leave the host. This host interfaces with underlying fabric using a NIC of variable complexity. Today the fabric is not multi-tenant and NIC is not really programmable.

The multi-tenant fabric is a focus of academic research. As always they will come up with a new tag that needs to be inserted after existing fabric tags. But its adoption will require the NIC based programmable silicon. This NIC needs be truly programmable (in  a programmable FPGA sense of the word and not SR-IOV VF sense of the word).

SOA and SDN - Lots in common

A decade and a half ago SoA drove an architectural change in software systems with the primary goal of loosening the tight bindings that existed between distributed components in a system. Then the tight binding was the language used (primarily Java). SoA was not a product, but it drove the roadmap of almost every product in the software industry. It created new products as well. Tight bindings made the software systems unscalable and brittle. SoA succeeded in that today's systems are more distributed and more scalable. Today's programmer has a choice of language. SDN too is not a product, it is an architecture. It too aims to loosen the tight bindings in the network systems - in this case a tight binding between the interface and the implementation (resulting in monopolistic markets). But the impact of SDN on the networking industry at least so far (4 yrs since OpenFlow) seems very limited. SoA drove a new serialization, new interface definition, new directory and a new wire protocol. SDN so far has done nothing of the sort. This could be because SDN is looking for a killer app. It is certainly not vanilla network management where it is applied today. SoA did not take off until a single webpage relied on 300 or more services to render the page. This technology was rapidly adopted in the social networking space. We are not seeing anything like this in networking yet. Cloud Networking or NFV may be those killer apps that SDN needs, but so far, we have not seen them drive any fundamental innovation into networking. SDN today is just a paper tiger. It needs a killer app and a real product to succeed. OpenFlow is increasingly looking like CORBA and not SOA.

Who is the cloud customer?

Will the real cloud customer please stand up? Most of marketing theory strives to correctly identity the "real" customer. Once the customer is identified it is a downhill task to cater to her/him. The problem is the real customer is always hiding. You would too if everyone wanted your money. Just like you don't answer the telemarketing calls at home and want to get on the do not call list, the real customer uses proxies to engage the vendors. In a cloud the customer is CIO who is still spending 84+% of his budget on fixed costs. That leaves him a mere 15+% to play with on his/her own discretion and most say of that only 5% is actually spent on innovation. His budget is under review every year from the CFO who has to keep showing a growing bottom line inspite of a flat to downward slopping top line. If you follow the S&P 500 companies where revenue growth for the last 3-4 yrs is under 5% (they are taking ORCL to the cleaners for missing even that today) and the divvys are expected to replace the lost income from the bonds (thanks to the pump from Fed), you will see very little room for the CFO to maneuver. Cloud offers the CIO more bang for the buck and hence this interest in cloudification of all assets. That pressure to reduce the fixed cost is driving software defined everything. Software can replace most of the fixed costs ('admins'), it can disintermediate the admin. This trend is driving a whole new industry in the area of configuration management and ever more user friendly self-service portals. So if you are designing a system that connects a super user friendly (read simplistic) to a sophisticated back-end (read complex system), you have to use a language that is different from the one you may have used to specify a menu driven desktop system.

Protocol vs. API: OpFlex

An API and Protocol both enable communication between two (or more if bus is involved) endpoints that are well defined and have address reachability. But API wins over protocol because of the flexibility that it provides over a static protocol. This is especially true in infrastructure management. With an API interface, one can support multiple management models including but not limited to programmatic (rpc, messaging), declarative (all those ini files or config-t command on Cisco IOS).


A key initiative in the cloud/virtualization industry is to open source every component in VMware's ecosystem. It started with hypervisor, then jumped the stack and moved to cloud management suites. What is not standard and open source yet is a set or inventory of managed objects. I am talking like managed objects that can be queried like exists at a much primitive level in SNMP. vCenter has such as inventory of managed objects and the industry should endeavor to create a standard and open source version of this inventory of managed objects.


Recently I came across a draft from Cisco on Opflex. I think the authors are attempting to create open src version of inventory of managed objects, but doing so in a very inflexible way i.e. creating a protocol for communication between endpoints. It would have been more useful had this initiative tried to create a framework with abstract objects that could be customized for the use case. The framework could offer a few basic services and define a few primitives. One of that service could have been endpoint registry, another could be endpoint profile. While it is positioned as a distributed system, it includes a domain which bring a domain controller into the picture.


What the cloud/virtualization industry needs is not another protocol but a SNMP like system that is open source but works at a much higher layer of abstraction instead of just device. We need to create a open source version of inventory of managed objects that can managed virtual resources that could run on any hypervisor.

L3 to Server

There is a trend towards moving switching (L2) out of the hypervisor and onto a NIC. After multiple false starts, it looks like it might actually happen.

Overlay networks essentially empower a virtual management tool or orchestrator to perform the control functions of a L2 network. The tool knows the full lifecycle of a VM and does not really need to learn any mac addresses. Coupled with a intelligent NIC and some standard based overlay (MacInIP), this tool can remove the need for a L2 switch in Hypervisor and facilitate bring L3 network directly to a server. If this happens, it will shift the network edge inside a server and shift the market power away from pure networkers to server vendors.

NfV Packet Processing

One of the key pillars on which the vision of NfV rests is optimized (meaning fast) cpu based packet processing. Sometime referred to as datapath processing in the cpu-mem complex without the need for any asic acceleration. No requiring any asic in the data path makes the cpu fungible (changed at will) and dramatically brings down the cost of network functions.

As we look at optimizations, we may also want to looks at why we have the ethernet I and II packet types and why the MTU min/max/jumbo packet sizes were arrived at. Do we really need the ethernet packet when the conversation is between two virtual machines on the same node?  Even across the host boundaries, but within the same data center, it is possible to have a conversation without having to create ethernet frames.

Hopefully we won't take existing VNFs and simply make OVFs out of them and run on a favorite hypervisor. Real NfV would involve refactoring the VNFs to use packet gateways for certain function and use standard RPC/IPC mechanisms for others.

Hypervisor based Overlays or Web Server based Overlays?

There  is a characterization of overlays as an abstraction as defined in computer science. An abstraction can be compiled down to the physical sometimes using an intermediate format. (like objects to byte code). Overlays are not abstraction, they are mark-ups and create a new layer for processing.  Mark-up are hints to higher layer software on how to process the content. There are services that these overlays need from the underlay and the exchange points are implemented in gateways.

Lot of complexity is being built into overlay networking because the design center of overlay networking is the hypervisor. By making hypervisor as a key node in the federated controller architecture, we are leaving out alternate mechanisms that enforce tenant/workload isolation like lpars/containers etc.  which don't need or require hypervisors.

Packets, Flows and Messages

I came across this post while doing the daily reading on SDN  https://devcentral.f5.com/articles/the-bifurcation-of-the-network-flows-versus-messages#.UjDVZ7Hn_mE. This resulted in a flashback as I recall sometime in 2004/5 time frame I was trying to explain to folks that message based switches are the way to go for then emerging service oriented network.

I would articulate the messages vs. tuple (flows) vs. header (packet) a little differently. In a service oriented network (and it is not SDN), the brain or intelligence bubbles up into a overlay network of proxies. Those proxies communicate among each other using messages. The brawn sinks down into a dumb data plane. The mapping between the two is done by "binding" to a transport. In those days HTTP was the transport but it was very apparent that it could not serve the purpose due to lack of asynchronous MEP (exchange). Today we are closer to realizing that vision.

Alas.. but we got hit on the head with murphy's law. In came SDN trying to disrupt the data plane by creating a centralized control plane. Except the control plane is not as intelligent as a the control plane of the original SON concept. It still works on packets. Fortunately, the byproduct of SDN hype is the real fruit of all this labor. That by product is programmability of the network device (not the network just the device). Today a message processor can read a route sent over the overlay of proxies and program the control plane on the switch to change the flow direction. This was not available in 2004/5. This was the original network virtualization concept. Virtualization because in the message processor you can have multiple tenants (although in those days we called it applications) and each one sees a different topology for its packets.

Big learning from that experience ... it hurts more to be early more than to be late.

Using Options Exchange to Price Cloud Computing

Traditional business decision tools like ROI, NPV do not sufficiently capture the risk in an investment decision on cloud computing. The demand for cloud services is not a sales forecast (linear) but more like a stock price (stochastic). Today this demand is met with a service that prices itself using an ancient cost accounting method, resulting in pricing models like pay-as-you-go or all-you-can-eat. The price does not take any market input. Imagine buying the stock of a company for a constant price regardless of the volume.

An option is an instrument that give you the right to buy the underlying security but does not obligate a purchase. Trading this instrument with underlying compute capacity as the security will help researchers and businesses study the demand for the cloud computing. Knowing the real demand and the market price for this emerging commodity will help guide investments for service providers and businesses. In the absence of this, we are going down the monopolistic pricing path that we are seeing right now. Except in the case of cloud computing, there is no government backstop for this monopoly.

SDN: Technology and Business Model

If SDN is an architecture, then what is the technology? Clearly it is not virtualization, in fact, most SDN architecture are not yet virtualized. It is not a protocol. The whole point of giving software the control is not to be constrained by a protocol. It is the API. API is what makes SDN possible. APIs like a network stack is not monolithic. There is the free API i.e .REST and there is the premium API which may or may not be proprietary - but will always be Open. APIs come with their own infrastructure and scaling that infrastructure is the challenge of SDN.

Moving on to business model of SDN. It is not in selling controllers. There are too many of them. It is not in scripting, integrating and scaling them in a cloud infrastructure like say OpenStack. Those are what is normally called out as NRE in the ROI spreadsheet. The business model of SDN is in hosting the cloud. SDN lowers the barrier to entry to enter the business of hosting.

So if you want to make money off SDN, get into hosting. If you want to work on SDN, get into APIs.

Internet of Things

There isn't just one web. There are many webs, the one we call web is the information web that can be browsed. There is a web being built that is invisible to a browser, it is the web of machines - referred to sometimes as IoT. As usual it is being met with cynicism, because we are not able to see the potential of machine to machine communication. Machines don't have to be physical devices, they can software logic elements. The communication transport does not need to be heavy weight, it does not even need to run entirely over existing TCI/IP transport. Some of the possibilities of IoT are obvious i.e. call home feature, automated trading floors, intelligent surveillance etc. But some are not so obvious. Take for example, your TV prompting you to watch a program because it read a note on your blog or read your profile and "understood" that some program running now is important to you. (apple tv take hint please). Or it knows using face recognition using kinect who is watching the Tv and adjusts the shows according to preference.

I would like the kitchen not just the refrigerator to tell me that the dish on today's cooking list does need an ingredient that I don't have or will run out of soon.

How about my shingles on my roof detecting the leak and sending their location so I don't have to spend hours on the roof with a bucket of water to find it.

Or how about my favorite.. ,(being the only guy I know who had to lost two cars to engine blow out because the engine did not enough oil and broke down)  where my car simply decides that maintenance can no longer be postponed and using  the yet to be developed or perfected driverless technology drives itself to a oil changer get its maintenance after dropping me at work.

Increasingly the innovation is in removing the human element from processes which ultimately makes the human more productive.

Cloud Requires a Market Maker

The business model of cloud computing is boiling down to keeping marginal cost of providing capacity to a marginal demand from mostly corporate user. Even though the cloud enthusiasts continue to believe all corporate computing will move to the cloud, it is not happening and unlikely to happen. The marginal demand though is moving to the cloud and many corporations are designing an overflow capacity in the cloud (kind of like line of computing account). Serving this marginal demand with capacity at a marginal cost that covers the service provider margin requirements is becoming the biz model of the cloud. We have seen the ramification of this on data center site selection and facility design. Now the ramifcations are becoming apparent in the infrastructure that gets deployed in these data centers. Few standouts are ...

Fungible is perhpas the most important requirement for any infrastructure that will be deployed in a cloud. No bells and whistles is another requirement. Basic bare bones is winning over hardened and over engineered systems. The datacenter managers use software to fill the gap between the skeleton and skin. Another standout is virtualization is not a  key requirement. In fact, as more applications onboard it is becoming apparent that cloud based service has to be hybrid of virtual and physical. All of these put together still not enable datacenters to serve the marginal demand at the lowest cost in almost real time. I don't think this can be solved technically, it  is really not a technical initiative, it is a market initiate. Makes sense as demand and supply are really market forces.  Customers engaged in price discovery need a market to query and a market maker to take the order. You can look at airline industry or the securities industry to get a feel for how this might evolve. Consolidators buy blocks of tickets at steep discount in anticipation of demand. Market makers take position in stock with similar intentions. In both of these industries the market maker is a critical element without whom the industry would not function.

This is what we need in cloud industry as well. Something or entity that plays the role of a Goldman or Priceline. I am waiting for the day when AWS starts a program which uses the rack of computer in my garage as capacity to sell to their customers. Kind of like the smart grid or SETI program. We may after all realize the vision of grid computing. The missing link is the market maker.  

Industrial Internet

May be they should rename industrial internet as software defined manufacturing or at least smart manufacturing. There is lot of software in manufacturing already mainly driven by precision requirements. The name, Industrial Internet, conjures up notions of a network hardened against hackers and natural calamities. Moving to software defined everything SD-* is essentially accepting that most basic intelligence today can be codified and stored in data bases that can be queried at high speeds. But that does not mean there is no room for software learning.

Software learning is where software does not just query for data but also reasons with the results of a query and draws inferences and acts on them. This type of software should form the base platform of industrial internet or just plain old IoT. When the devices on you connect to one another not just at the bluetooth layer but at a application layer. For example, when a device playing music is in the vicinity of a speaker, it switches to the speaker (after asking of course) or when you suddenly brake your car to avoid an accident, the video and music playing devices inside the car stop to let the passengers focus on the road, or the same behavior when listening or watching movies in an airplane.

Solution is a state not a path

Networking is going through a identity crisis. Is it a special device or just a program on a commodity machine? The crux of the problem lies in a shift in the problem space where networkers spent all their time. The solution to a networking problem today is not the best path but the best state. In the early years this branch was taken by networkers because in those finding the best path in a graph was the solution to getting the applications (in those days printing, later email) to work. But today, a simple struts application has more action elements (routes) than a BGP table on internet. In other words, there are more paths a browser can take after it has landed on the web server than it had to take getting to the web server.

When state mangement and control is the problem, the solution is software. The paths are discovered and known what matters now is the learning on which ones for which application. This is what is causing the identity crisis for networkers which then manifests itself as SDN, Programmable Networks etc. Also the reason why the largest networking company flips flops between we are going to focus on networking to we want to be an IT company. Hope it does not do what freeport did - a copper company acquiring a O&G company.

State Description Language

After almost a decade after WSDL - the service interface description language - was introduced, I think it is time for industry to create a state description language. Just like WSDL enabled communication of interface between the two points engaged in a conversation (or any other MEP), we need two infrastructure components inside a data center to communicate their state among one another. The end goal is autonomic data center where a component "learns" about the fellow components and reflects and adjusts its own state.

Application integration is easy today. Everybody has an API on which default information (useless) can be communicated. But to use this new found connection we need to develop languages that enable communication about data, state, intention etc. The whole movement to cloud has commoditized compute, storage to a point where $5/month can buy me more IT infrastructure than my university had when I was studying engineering...

Biggest Bottleneck in Bigdata is the human

Today's WSJ carries an article on Bigdata being the brain behind hiring in companies. There are lots of Bigdata articles all around and each one points to a new bottleneck for the industry to overcome. There is one bottleneck that no one discusses. It is the ultimate consumer of Bigdata - the human. If we have trouble getting computers to deal with Bigdata, imagine presenting the analysis to a human. We are simply not wired to consume all this analysis. That is where visualization steps in.

So what is visualization of Bigdata? It is the rendering of insight in a data analysis using images, animations, selective disclosures, progressive disclosures or charts/figures/clouds/bubbles etc. The challenge here is not in rendering these visual elements, but in mapping these elements to the data that is sourced across the internet, parsed by multiple parsers, collated/curated and correlated with multiple streams and displayed on a canvas that is hosted in yet another place. Then there is the debate of HTML5 vs native too.

Visualization of Bigdata is a field actively targeted by research community and there is a strong business case for it as well: it solves the biggest bottleneck in the bigdata ecosystem i.e. the human.

IM is the Best Overlay Network

Under the moniker of Software Defined Network or SDN a flurry of new technical proposals are vying to become the next standards. The business case for them is very sound i.e service providers after failing in their first attempt in late 90s and early 2000s are now confident that there is a way to monetize services which run inside datacenters. The problem is of course the scale at which they need to operate requires that services run across traditional boundaries set up by networking. To cross these boundaries they are devicing clever ways of getting bits across a policy boundary using overlays (envelopes inside other envelopes). The debate is lately on which layer's envelope shall I use. Layer-2 or Layer-3.  Ok, so at the end of day what is needed is a mechanism that abstracts the underlying network and presents it to the applications over sockets in a programmer friendly fashion .

What the networking guys need to do is to look at how this problem was solved in application world over a decade ago. Hint: Use HTTP for control plane, XML for management plane and whatever you want for data plane. The best overlay network in the world continues to be IM (instant messaging)

SDN vs SdN

May be they should have define software Driven network  as application driven network so as not to confuse it with software defined network (openflow and the rest...).  The former is all about network applications using the open APIs on the network to provision, reserve and optimize the path that the application data takes. The open API could be network as a service. The ultimate goal of this initiative is programmable network.

The latter is a rearchitecture of the switch with focus on virtualization of the hardware forwarding plane. A multi device network operating system and bunch of controllers that use use the NOS to configure the devices. The ultimate goal of this initiative is operational excellence.

Innovation is its own Business Case

"What is the business case for this innovation?" Heard that?

Innovation or lack of it is the reason for 2.x% GDP growth in the developed world and we still hear this call for justification. Fed funds rate is 0-0.25% and yet we have to justify NPV of a project. Everybody from company president to the country president is asking (no begging) for innovation, but we need to prove ROI for a project. The chinese did not need a business case to build so called "Ghost cities". They consume 40% of copper production in the world without business case. They are the equivalent of Apple in the world today with surplus cash to buy out several greek deficits. They even placed their machine on the Top 500.

Innovation is its own business case. You cannot calculate the ROI of innovation because you cannot measure the return. So think of the "I" in ROI as your ability to finance (means) and risk tolerance.

SDN

When J Hamilton said network gets in the way, I believe he was asking for a economical solution kind of like the way x86 based servers replace risc processors. The x86 world did not bring complexity, unknown paradigm with unknown cost and difficult to estimate performance. Software Defined Networking a.k.a SDN is apparently doing just that. What started as simple protocol to read/write/replace entries into a switch's forwarding table now has attracted a code bloat and frameworks which promise a network which does substantially what is already done with VMWare's vswitch.

The original call to simplify the network listed a few use cases as drivers which can be categorized as 1) Workload placement (includes all shapes/forms of vm mobility, code mobility etc.) and 2) big data processing. The first challenge attracted solution such as overlays and tunnels which can extend a vm's notion of its layer-2 domain within and across datacenters. What we need now is a standardized way of doing this not a new framework which disassembles a network devices data, control and management plane and places one or more of those on general purpose CPU. We had already done some of this in the olden day with Infiniband's subnet manager and come to the conclusion that it does not scale for dynamic workloads. The second challenge is still in the process of becoming a challenge. With all the hype behind bigadata, an average cluster running bigdata analysis is under 40 nodes. Even Hadoop does not scale beyond 4K nodes.

What the datacenter really wants is a cheap network switch that cost no more than $10/GByte of traffic in motion. $10/GB is the same metric used to guage the efficacy of storage service. It should not cost more than $10 for a gigabyte of data in store or in motion (on the wire) and in the future in memory on the compute side.

Hadoop - Still full of potential

Japan's K-Computer has 705K cores stayed on top of the Top 500 supercomputer list. Now that is scale! I am reacquainting myself to Hadoop to which I was introduced in 2006 and find it is still using stateful nodes maxes out around 3-4K and does not use network storage. Security is an after thought and it is not yet suitable for its killer application interactive behavioral processing or the future killer application real-time stock data processing. If I were to add cloud related requirement of multi-tenancy, virtualization, billing etc etc. you see how underdeveloped this system is and how big its potential is.

BigData = HPC 2.0 and Network 2.0 and reduces healthcare costs

Mckinsey report on big data . http://www.mckinsey.com/mgi/publications/big_data/pdfs/MGI_big_data_full_report.pdf Excerpt from this.. For instance, if US health care could use big data creatively and effectively to drive efficiency and quality, we estimate that the potential value from data in the sector could be more than $300 billion in value every year, two-thirds of which would be in the form of reducing national health care expenditures by about 8 percent May be the republican candidates should study big data ; they are far easier to remember than three agencies...

Cloud Storage

I ran into the letter to stockholders for AMZN. http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9OTA4ODB8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

It does not read like a letter that a retailer sends out to its stockholder. It reads more like a conversation between two technologists. AMZN realizes that if it only gets to store/manage 2% of the 500 Billion Gigabytes of data that exists in the world, it could earn at the rate of $1.2M/Petabyte/year enough to more than double ths stock price from its current (often considered lofty) levels.

NIST Cloud Standards

NIST released its cloud computing standards July 5th. Besides the standard definition around delivery models and characteristics "What" of the cloud, what stands out to me as the most important element of cloud computing is the definition and standardization of the roles in cloud computing. More specifically, the definition of the role "Cloud Auditor". With increasing deployment of clouds, this role becomes about as important if not more as the "Cloud Broker" role.

25 Pts of Execution for US Gov

It seems besides the markets (through QE-2), the Feds are also in the business of propping up cloud computing and IT in general. Here is their new plan - 25 points to reform Govt IT

Here is something that might be of interest to folks "800 DCs to be closed by 2015 as part of Cloud First Policy"

I have been saying for a while now Cloud is about saving $$. It is not about selling more stuff into a account. In fact the overall DC TAM is expected to decrease after Cloud Computing has done its thing. CIOs want it to decrease by at least 30% and vendors want to make sure the remaining 70% includes their wares.

Cloud Computing SOU

Interesting findings from Zenoss study on CC. Flexibility is now the leading driver for virtualization ahead of capex savings. Even though 90% of startups are working on products with a value prop that is a variation on "Managing VM Sprawl", only 26% of customer have deployed a tool to manage virtual infrastructure. So apparently, the customer is not driven to virtualization based on capex or opex savings. What gives?

Actually this is kind of good news. The whole cloud thing was hijacked by "Opex Savings" value prop i.e. management automation etc. around late 2008. The original cloud vision of internet as a platform (like OS today) was put on the back burner. May be we should get back to the roots of the cloud.

Framework for Network Svcs Deployment

If we refer to the bubble years as the "siliconization" of the network services, then today we are experiencing "containerization" of the nework services i.e. all network services need to be ported to a container that abstracts the oddities of the underlying platform and manages all non-configurable parameters. In addition, it offers the run-time for the control plane of the network services and leverages PCI architecture's VF to leverage HW acceleration.

Should this architecture win in the market place, it will have a profound impact on the networking industry.

HTML 5 Demo

The site http://www.thewildernessdowntown.com/ shows what media made specific for a browser will look like. It uses HTML5. HTML 5 has every thing (but double buffering) that a media designer wants. 3D engine for rendering, texture mapping, color correction, sequencing, audio and video support.

Changing Traffic Pattern on Internet

The absolute traffic on internet is rising but the nature of the traffic is changing. Another way to look at this is 77% of traffic on internet is social networking related and supported by advertising based business models.If you are a proxy device for the web and support FTP, DNS, and HTTP then this data point should get you thinking.

Content as a Service

IDC says the industry spent $16B in 2009 on public clouds. The spending includes HW and SW.


Besides the fact that they don't have a network spend category, what stands out is the increase in relative spending in the App Dev category. Increase in tooling related spending can means that atleast until 2014, IaaS continues to be the dominant service model. End user spending on tooling suggests an increasing ecosystem of cloud enabling tools that enable hosting and interconnections on various available IaaS clouds. Another stand out is decrease in application spending. If we are to believe the three service models I/P/SaaS then we should be seeing an increase in application spending (also PaaS should decrease the tooling costs).

Another interesting data point is incremental spending is still leaning in favor of traditional IT. If in 5 years we are still spendig 2/3rd of incremental dollars on traditional IT, that is not good news for Cloud Apps.





Yet another point which was not surprising at all is increase in storage spending. It may also hint at a cloud that is vastly different from ones which we read about in trade rags. Instead of applications on the cloud, we could just be moving to media in the cloud. Instead of end of enterprise IT as we know it, we may be heading to end of entertainment as we know it.

VM Density

Cloud economics are most sensitive to VM density and less to automated virtual infrastructure management. If the VM density decreases as self-service portals are introduced or SLAs enforced, it will undermine the cloud economics.

The way to increase the VM density is to offload functionality from the VM that creates headroom or "idleness" in CPU, memory and IO. Creating virtual versions of network services as VAs is exactly what you don't want. Having a footprint on the virtual server backed up with HW acceleration outside the VI is what will increase the density. In other words, virtualization of network services is not a P2V activity but more a distributed computing exercise

Datacenter - Network as a Service

SOA is not a product, but an architecture and the prescribed approach is now finding its way (quite violently sometimes) into the network. Let us start with the framework. We need to create a point of indirection between a network device (the service provider) and the end station (service consumer). That point of indirection is the repository where network devices register their service and its scope. The same repository should support a querying mechanism that returns a service description to the initiator of the query. We need a stack on the initiator which understands the description (i.e. no human involved) and can initiate a peering relationship with the service provider whose service description was returned as response to the query. We also need the repository to differentiate between a cataloged service (inventory) and a service instance (presence). We also need the repository to be available at a well known address because the network device is factory configured to find its repository. Finally, we need a service that creates this repository service should one not exist (when the first network box is deployed for example).

The next question is what is the protocol of communication that will support a conversation between the end station, repository and peers that are present. This is where folks gets in own way. For cataloging, we don't need presence information and for presence we do not need to be cataloged. One requires a session oriented protocol while the other requires a simple request/response. Both these protocols exist in inustry.

Where further work is required is description of the service and that is where the crux of the whole architecture lies. Here we need to take care that we don't fall into the trap of describing our CLI as XML.

Java CE (Cloud Edition)

Virtualization and its live migration is becoming an innovation blocker. Recall that the original problem that we are trying to solve is "How does an application get access to resources on demand?" In other words, how do we get an operating system that scales to an entire datacenter. Even with virtualization my application is contrained to an operating system.

What we need is a language run-time like JVM that talks to a hypervisor directly. What we need is a hypervisor that abstracts resource for an application at a level that the application understands i.e. tables, databases, files, serversockets and clientsockets, IO etc.

JeOS (Just enough OS) is a slow-start in a wrong direction. What we need is JNOS (Just No OS!).

Cloud needs Resource Reservation & Broker

A key element of the infrastructure that will form the cloud is resource reservation and a protocol that enables applications to reserve the resources. Without this element we can't have a credible SLA offering. But this reservation system has to be integrated into the billing system as well as the customer entitlement system.

Today's oversubscription systems allow contending processes to carry entitlements, however those entitlements have no basis in economic value of the user who initiated the process. For example, in VI, one can allocate shares to compute elements but those shares do take into account the customer's SLA entitlements. Neither did I see anything in the recently released vCloud API anything that says someone is thinking about it.

Since the days of Cluster/Grid, we have been making pretty powerpoint slides showing the business value of IT to customers. Cloud is supposed to provide the mechanisms for the customer to harness/govern the business value.

Policy vs. Mechanism in Cloud

Existing architectures come embedded with their own policies with little control left to end user. It appealed to the enterprise customer as they only had to learn the knobs and how much to turn it before the product starts to smoke. This is about to change in Cloud Computing.

The forceful intermediation of an economic model into the use of an application (which the main difference between cloud and a cluster-grid) is disaggregating the policy definition point or PDP into multiple tiers. This is similar to what we saw happen to policy enforcement during the development of 3-tier datacenters in late 90s. A policy defined at the CSP level will be inherited, extended and enforced at the enterprise IT level and further changed and extended at the end user level. This requirement of the cloud will create a bias in the architecture of a system towards mechanism and policy negotiations.

The policy vs. mechanism was a hot debate in early 90s and looks likely to return once again.

Cloud CPE

Hardly anyone mentions the need for a CPE which IMHO is a requirement for a cloud computing model. Today MSFT announced that their next version of Office will have a free online version. But one of the big features of a cloud is "offline browsing/applications". That is the only way to protect oneself from highly publicized outages at Amazon a few months ago and Rackable a few weeks ago.

CPE that enforces local security policies including authentication & filtering. Offline browsing and metering is a business model requirement in cloud computing.

The other function that is hardly discussed in CC discussions is syndication. I have been trying to add an animation/3D module to Google's online presentation (powerpoint equivalent), but not even google has open plug-in architecture to enable this. Unless folks think that Cloud is just another proprietary application running on the network, this functionality is the key extensibility requirement for a useful CC app.

MMOG is the true Cloud App

MMOG or Massively Multiplayer Online Game is a widely used cloud application that never makes it to any discussion on cloud computing. MMOG is expected to be $9B market by end of this decade with its ground zero in China. WOW (World of Warcraft) which debuted in China reached a peak concurrency of 500K users. These cloud applications have tens of millions of registered users with millions of daily visits. This industry has spawned an ecosystem around the applications with operators called MMOs. As with all technologies they have now introduced open platforms for games.

These gaming platforms have already experienced the issue that business oriented cloud computing platforms and later operators will face.

Appleap.com shows which games/apps are the most popular on Chinese SNS.

Servers for Clouds

Three major segments of cloud computing Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), Software-as-a-Service(SaaS)

PaaS
force.com
googleapps
longjump, bunjee labs,

DNS is part of the cloud

With all the automation promised for an ISV in the cloud, there is a need for a service that most of us take for granted. I had blogged about it almost a year ago, but only recently figured out that I was only scrapping the surface of the problem from a cloud perspective.

If seven ISVs use the same cloud, whose DNS service are they going to use? Inside their cloud operation if an IP address is generated for a machine, how does a Java process open a socket on it? You cannot hardcode IP addrs. How can app guy write an application now that could be deployed behind any FQDN at any cloud. Cloud has multiple zones, how will the app developerknow the zone?

All of these issues cannot be solved by using DNSaaS. Some device inside needs to enable this.

Cloud Application Programming Model

Most of the definition(s) of cloud computing highlight just one of its dimension i.e. scale of the application delivery. Cloud computing, they say, is about internet scale (millions of simultaneous connections)application access that is hosted at a WAN latency distance. While remote hosting is an important characteristic of the cloud, it is not really, IMHO, the most important one. Back in late 1990s, we experimented with hosting applications remotely. That failed. It failed because the programming model did not evolve to accomodate distribution of functionality across WAN latent connections.

In today's Web 2.0 world, we have new page elements which can be dropped into a page which invoke remotely resident applications. This document management inspired model needs to evolve into a programmatic model for real cloud computing to happen. Document management paradigm is not an evolution from object oriented paradigm that is dominant today. The efforts that went into discovering the most efficient way to migrate object oriented programming to the web got lost in the endless debates on SOAP vs REST, Sync vs. Async, Language vs. Description etc. etc.

What a programmer aiming to write to cloud really wants is a way to import a library (java package for me) which is resident in a SDK that is installed somewhere on the web. This way I can import any java package that is somewhere in the world and access any database that is hosted anywhere in the world and have a class object sitting in my local directory that I load into any JVM on any device.

May be it is time for Sun to create a J2CE (Cloud Edition). J2CE should not require me to download anything other than a Netbeans IDE that has built in well know SDK locations that are resident around the world.

Bungee Jump off Puenta Iglesia over Rio Colorado

My first bungee jump off a bridge in south america over river Colorado. The bridge is 80m over the water and the bungee chord extends to within 20m of the ground.




I checked with AIG, if there is a mishap during a bungee jump, they don't pay your

Application Streaming

Here is a problem... You want to increase the bandwidth per pin on a chip but power budget dictates that the core cannot be run faster. So you increase the number of cores and buffer to meet the bandwidth per pin. Why is this important to application streaming?

Systems are deal with real-time information do not have the luxury of disk storage. Most of the RT information is computed inside the chip complex and semiconductor technology places the current bottleneck at the pins. To remain real-time, we need to get the information off the chip and on the network on its way to its consumer as fast as possible. If I am a remote consumer of information, the core that is provisioned to me is not the bottleneck but the pins that it drives to get data to my handheld is.

So I have now resigned to the fate that my desktop will be hosted in the cloud and my service provider will charge me for the resolution at which I interact with it. Higher the resolution, higher the charge. I am sure they are not thinking that people will be sharing a remote session on a server like 1970s mainframe. What will make people give up their local desktop is if the desktop is like TV. Consumer buys the screen and the service provider delivers information. Service providers also differentiate among one another through the range of supported peripherals like today's MMPOG (games).

All of this puts the emphasis on application streaming. Moving code to client for execution is not going to fly. To make it usable, I need a thick client and that kills the cloud economics. Remote session is too slow. Streaming looks like the only approach right now. And for it to be useful, the chips need to increase the bandwidth per pin.

Location Based Services

At Apple's WWDC Jobs said there is a proliferation of LBSes on the mobile. Having a GPS inside the phone provides location as a parameter for all applications. I do not think there is a class of services called LBS. Classes of applications on the mobile generally fall into four categories

1. Sync and Search which are data intensive

2. Mapping which is graphics intensive

3. Social/Sharing which is network intensive

4. Monitoring which is sensor intensive.

Of course there is the voice and other standard media player type phone functions that we already have.

All these categories will benefit from location. But the point is there is no one application called LBS. Also, more services will be delivered to the phone over its wifi network than over its cellular. The phones add on functionalities at a far rapid pace. The carriers simply won't be able to keep up.

Mobile Applications Framework

If you play with the various mobile platforms out there such as Android, LiMo, S60 etc., the one thing you will notice is that application development frameworks on these platforms are quite immature. One of the big advantages of having a framework is to not have to write custom code to reason with a new resource type. JDBC essentially created the whole application server market. We need something like that for mobile applications as well.

Mobile frameworks are essentially client side libraries that hide the myriads of APIs that are available to access resources over the web.

Home Area Network

Did you know that an average american household contains appliances that use at least six different network protocols everyday. They are

1. Cordless Phone Network
2. Bluetooth Network
3. Cellular Network
4. WiFi Network
5. Cable Network
6. POTs network

This does not even include the many remote controls which use point to point proprietary protocols. Remotes like

1. TV/Audio or Anything IR
2. Garage Door Opener
3. Keyless Entry on Car

And increasingly the devices on these networks are not stateless. When I add someone to my cell phone's addressbook, it does not automatically update the addressbook on the cordless at home or outlook on my laptops and desktop. When I talk over Vonage, something should automagically throttle a mp3 file being downloaded.

There has go to be a switch which can switch control/data over these networks.

Buttons on the Web

The industry keeps searching for the next killer application when it is sitting right in front of us. All we need to do is add functionality to it. The killer application is the Web and it has buttons.

The first one (circa 1995) is called "View". We click on this button and we browse the web, view videos and listen to audio. It is now called Web 1.0.

Then we started to notice a new button begin to appear on the web. With time we could read it as "Edit". Using the functionality provided by this button, we can now edit wikipedia, blogs and podcast ourselves. This button's backend infrastructure is being developed at companies such as Amazon, Google, Cisco (Webex), SF.com etc.

Once again there is a new button that is appearing, but people can't quite read its title just yet. Those who can read it are making frequent rounds to their neigbourhood venture community. Unfortunately, but for a few select ones, they will see it when it is too late. That button is titled "Run". Yes, the same thing as when you press the "windows" key + "r". The coolness of this new button is you can pretty much type anything (assuming an application exists) in the run box and it (the applicaton/service) will appear from somewhere on the web. You can use the application as long or as little as you want and save your results to local disk or a webdisk. All of this as part of subcription from your friendly ISP.

Hope the industry can rally the resources to fund and develop this new infrastructure to support this "run" button. This is where the next Google is going to come from.

Tata Nano Design Should be Open Sourced

While the whole world is focussed on the price of the Tata nano ($2500), I think the biggest innovation coming out of Tata Motors (TTM) is the packaging and delivery that is enabled by a modular design. Nano comes as a package to your door and you can assemble it.

What Tata should be doing is open sourcing the design of the Nano along the lines of GPL. This will spark a revolution in the auto industry with Tata as its spiritual leader. Tata could build a cult of enthusiasts around the world who will mod the base model and add to the open source IP of Nano.

Tata may want to take a few cues from IBM's experience with design of the PC. PC was based on open architecture. It was not IBM that made money on the PC but Microsoft and Intel. What Tata should do is open source the design and make money on the engine and gadget-ware that go with the car.

The last time someone open sourced the design of a manufacturable product, it turned into a ubiqutious entity albeit with notoriety. Yes, I am talking about AK-47 rifle. Tata has the opportunity here to make the world's first open source car. Common Ratan Tata, just do it for India Yaar!

Theory of Virtualization

IMHO, virtualization is about what resource you want to hold constant and what you want to scale. The most popular version of virtualization is where one fixes the hardware configuration and scales on hosting environment. This type of virtualization done by VMWare/Xen etc. is what most people think of when one says virtualization. We can generalize this to define virtualization types based on which one or two resources one holds constants and which ones one scales.

I think virtualization as a field is function of hardware, hosting environment, collective and application and of course the user (identity).

Virtualization Types
Hold Constant	Scaling Dimension	Type
Hardware	Hosting Environment	VMWare Type
Hosting Environment	Hardware	Grid Type
Hardware & Hosting Environment	Identity	Single Sign On
Hardware, Hosting Environment, Identity	Applications	Web Application Delivery Type

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

AON Devices - Server Appliances or Network Appliances

Ever since Cisco announced its AON and now SONA strategy, every SOA appliance vendor has embraced the TLA "AON". The definition of AON however is still as ambiguous as its server side counterpart ESB. IMHO, the answer lies in answering the question "Are AON devices server appliances or network appliances? "

A server appliances is a network attached closed server that performs one function i.e. offload the server. All the devices from SOA appliance vendors available today do exactly this. They offload security processing from the server. Some of the ambitious ones will offload business process orchestration from the server. All of this is to optimize the performance of an application that adhers to SOA principles. A server appliance is sold to a server system administrator.

A network appliance is a "in-line" network device. It does not offload processing from a server. It simply redirects, routes application flows to servers which are attached to the network. This routing is based on metadata that is part of the payload. This single function differentiates it from a standard router which only looks at packet level information to route a flow. Using a network appliance, one can create a VLAN which is SOAP 1.1 only. One could create a load balancer which distributes load based on transaction identity and not just sessions. A network appliance is sold to a network manager.

I have heard folks say network managers are not knowlegeable about SOA and its protocols of communication. Well, they were not aware of HTTP and web protocols in 1995. But they are well versed in it now. The reason these folks are not interested in talking to vendors, is vendors keep taking a server appliance to them and try to sell that as if it were a network appliance.

Cisco's SONA

Cisco announced its SONA (Service Oriented Network Architecture) www.cisco.com/application/pdf/en/us/ guest/netsol/ns477/c643/cdccont_0900aecd8039b324.pdf.

When implemented correctly, a SONA like architecture will allow an administrator to login into a network services router and run "show http peers" which will list all the web services that are exposed using http binding in the network. Replace "http" with your favorite protocol and you should be able to see web services exposed on your favorite binding. If you type "show some_peer_webservice", you should be able to see its various bindings, its "EPR", its grouping and almost everything you get from WSDL of the service (without the annoying angle brackets).

Moving web services network management away from developers into the hands of operations personnel is the true promise of SOA and SONA delivers on that promise better than any application server centric (open or otherwise) service bus.

Development vs. Deployment

The industry has spent the last five years or so to get a conceptual, architectural buy-in for web-services. The standards related to web services, generally referred to as WS-*, too have gone beyond proprietary workshops to standard bodies' technical commitees. Surprisingly all of this effort was driven by developers, for developers and of developers.

Web Services have a reached a point where if they don't cross over from the developer domain to deployment domain, there is a very real chance that this whole effort will be for nothing.

A key stumbling block towards deployment of web services is lack of real products which embody the technology developed in standards and employ the principles behind web services. While every vendor has a web services marketing program, very few have real web services products. No wonder the few customers who had the resources and implemented web services as pilots are being claimed as the reference customers by every major vendor.

ESB vs. Application Networks

The article by Dave Chappel provides a good description of what ESB is and its roadmap. However there is one critical architectural flaw in ESB. In trying to scale ESB, one has to scale the container. This is very difficult task as we all know from trying to scale other industry standard containers such as J2EE.

IMHO, application networks are better choice for scalable services that ESB offers. The reason is that in a network it is not the control but the data path that is scaled. From networking, we know scaling a data path is far easier than scaling a control. A highly scalable data path with distributed control across the service network can provide all the services of an ESB without the concomittant headaches for IT of having to integrate another layer of middleware on top of already difficult middleware landscape.

Application Networks

There is a lot of buzz on application networks where applications are stitched together using the functionalities exposed by today's large enterprise systems as web services. Before we start to dream about such application networks we may want to put on our systems engineering hats and ask if we even have the underlying infrastructure to support such networks.

Starting at the lowest layer which is all about computing horsepower and storage capacity. With all the efforts around virtualization and on demand everything, we still don't have a compute or storage grid on which such applications can run.

While Grids find their afficionados in the distributed computing field, the Grid as such is more a network related field. In fact, Grid computing is about decomposing a compute problem into a networking problem. This brings us to the next higher level layer in application networks i.e. the messaging fabric. There is no such thing today. All we have today is a few isolated bridges and routers in the form of MOM middleware but nothing that can remotely be classified as infrastructure.

The top two layers in the application networks deal with business logic and processes respectively. IMHO, these are the easiest of the layers to build as they are the most application specific.

MTOM/XOP/RRSHB

Finally these specs are done. For those unware of these specs, there is a good intro in this article.

The key questions for me remains if these specs finally enable code mobility across the network?

Code mobility is a big requirement in the embedded devices from switches to PDAs. It is also one of the key services that should be offered by a Grid.

Cisco Getting Into Web Services

Looks like Cisco is getting into web services and middleware.

This is not surprising at all. Just look at the history of Cisco and networking. Everytime the transfer syntax was standardized at a layer in the OSI stack the functionality of that layer migrated out of the server and into appliances like switches. XML and SOAP help standardize the transfer syntax at L6/L7 and now we should see a network at these levels as well.

The ramifications of having a network at these levels is quite profound.

We have to get used to new vocabulary like application overlay networks or service oriented networks. On these networks one can resolve among two components of an application and provide differentiated services to those components just like today's network resolves among two IP addresses and offers differentiated services to each. (Hopefully the guys defining the WS-Addressing specification are reading this).

Instead of a synchronous API call, a developer simply sends an asynchronous message. This message has to traverse a path across heterogenous systems, multiple transports and now-a-days multiple brokers as well. For this to work we would need switches/routers that offer a fast path based on middleware based control.

Applications themselves have to be choreographed instead of developed-- just like today's business process.

The guy who wrote the HBR article "Does IT matter?" is going to be quoted like IBM's CEO who said the world only need two or three of his mainframe computers ;)

An interesting article on web services standards that you can find here
Computer Magazine - Are Web Services Finally Ready to Deliver?

An interesting quote in that article is that web services' developers are not aware of which standards (defined by W3C/Oasis for interoperability) they are likely to support. Ironically, the whole point of web services is to remove the dependence of interoperability on software coding habits. So it is a good thing that the developers don't know!

The interoperability of components needs to be configured at deployment time not development time. Most of the business code today is written on some sort of container abstraction. It is the responsibility of the container to ensure interoperability of the code that it manages not the developer.

Now who hosts those containers is another debate. Today containers are hosted on some OS running on a GPS. Perhaps it is time to migrate these containers into some fabric which takes care of these low level details and offers fabric wide management functionality.

REST Debate

Anybody involved in web services is probably super familiar with the REST debate and probably figured out how to write the filters to filter out the emails to an appropriate folder for offline reading.

From a for-profit product company this debate adds absolutely no value. Customers are essentially resolving this dispute through their use cases. Having spoken to multiple of them albeit from one vertical it looks like the field is using XML over HTTP for presentation traffic (to and fro from a browser) and SOAP over HTTP or JMS for application to application traffic.

So if your product is anywhere close to the tier-1 of the datacenter be prepared for lots of XML coming down your HTTP pipe. If you device is in the second or third tier of the datacenter (like an app server for example), be prepared for majority of the traffic being SOAP.

Adaptive Systems Salient Features

Building a building block in the next generation adaptive enterprise is not easy to say the least. The most difficult part is not the complex mechanisms that constitute an adaptive system but the complex communication patterns that emerge that need to be controlled.

So I thought it would be a good idea to put together a list of salient features of any adaptive systems. Here they are..

1) Hierarchies: In any complex system, there is bound to be an hierarchy or multiple hierarchies. To make things even more difficult to implement, these hierarchies are based on loosely coupled entities which join/leave the network as and when they please. The biggest issue of this characteristic is in finding the best addressing scheme.

2) Aggregation: Aggregation or grouping is another characteristic. These groups are short lived or long lived and can form dynamically. Their boundaries need to be represented syntactically in the system and access in and out of this boundary needs to be controlled.

3) Communication: The foundation of any adaptive system lies in it's communication substrate. Communication in such systems is generally a conversation rather than a fire & forget type asynchronous communication or block & timeout type sychronous one.

4) Control: Control is the method to the madness. Unlike conventional systems, however, the control is not static and hardwired but dynamic and mostly embedded in the interaction.

5) Non-Linear Behavior: Unlike your SNMP type faults, faults in such a system cascade into really big blackouts. Fault control mechanisms are there not your traditional "call home or email admin" mechanism but more like circuit breakers. The ability to counter a cascading fault is the true gauge to robustness. It is not about 5 nines and MTBFs.

6) Finally, separation of form from function. I believe I blogged on this when I first started on this project.

Ok, now to implement such a system what has computer science given us? Well, so far just two concepts (a) abstraction (b) virtualization.

SOA Network

The article discusses the requirements for the underlying network for SOA to function according to it's claims. While the author has mostly borrowed from existing white papers, there are a few nuggets of gold in there. Here are my thoughts on a few points the author made.

...."An SOA is a business process-driven application integration architecture in which all functions, activities and actions are defined as services and use standards-based interfaces."

This gets to the core of what a SOA network is all about. Business processes are driven by events and the SOA network likewise has to be driven by events and not just traffic patterns and traffic engineering as is today's network. Pub/Sub event distribution model is more suitable for a small installation but for any size of installation worthy of the name "network", this model is not totally not suitable.

The missing link in today's network's readines for SOA is scalable event propagation to entities on the network and the ability to resolve among those entities. Once this is done, the bit about securely and reliably sending messages is straight forward processing and thanks for web service enabled standards, quite interoperable.

.... "But in the end, the SOA's business benefits will outweigh the cost of implementation. "

Amen to that.

Application Networks

The PSTN is the world largest network dedicated to one application i.e. telephony. It works really well, has great QoS and costs a few cents/minute. It has a great business model that supports around $800B dollar industry and employs a few million people around the world.

Look at another network the internet. Supports millions of applications none of which have any QoS, costs a bundle, Does not have a business model that works and employs well in tens of thousands.

Is something wrong here?