Friday, June 20, 2014

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.

Tuesday, June 03, 2014

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.