In one phrase: lack of interoperability.
Now the reasoning behind the phrase….
ProtocolBuffers is a language independent data format and a set of tools or libraries which Google released into the public domain a few years ago. The unique selling points are language independence and high efficiency / performance. ProtocolBuffers RPC is a remote procedure call client and server side “interface” specification which utilizes the protocol buffer messages and defines “Services”. The RPC api has some very interesting features which are arguably interesting for service providers – like call cancellation, and asynchronous callback on completion.
Now the ProtocolBuffers serialization is very performant – much more so than say SOAP WebServices. Unfortunately Google did not release their own implementation of a RPC library into the public domain. This would not be a problem if they had defined a standard which would standardize interoperability of the RPC services between different implementations – between clients and servers made available by different parties with differing technologies and programming languages. The lack of a “wire format specification” in particular
- means providers need to provide own libraries in all supported languages if they want to achieve a reasonably wide adoption. The current list of Official RPC Implementations shows that most libraries only support 1 language. A few RPC implementations support 2 languages, and the only library ICE which says it supports multiple ( all ) is not actually an Protobuf RPC implementation, but a library which was an existing multilanguage proprietary RPC library which was just extended to support Protobuf message payloads.
- means software vendors cannot choose one library since they’re not compatible with other libraries. For example JBoss application server would not use Tomcat if it were not a standard web application container.
Google could do things differently – example Thrift from Facebook. Thrift provides a reference implementation with each language binding. Having said that, I do appreciate why Google was not prepared to release their RPC implementation(s). You need more than just wireformat to define interoperability. For example
- a service naming concept – or “directory service” ( DNS ). Cloud service providers find themselves partitioning services – not all service providers are going to load balance behind one hostname.
- application layer identity management, authentication and authorization mechanisms
- transport layer security and protection mechanisms.
- logging mechanisms
- accounting mechanisms
- monitoring and administrative remote control of all the above.
I guess if Google were to release an implementation which did all the above, they would be giving up some of their very precious strategic operational advantages.
The DomainNameService (DNS) is arguably the most important internet service in existence today. Without it, the internet would not work as it does today, not email, not web browsing, nada. DNS is what gives a logical “name” to the “internet address” which every device attached to the internet has. Only in the most security conscious environments, where all forms of DNS attacks need to be avoided, do administrators setup collaboration between internet attached devices using IP addresses alone – forgoing DNS. For example enterprise VPNs and Telco equipment. This practice boils down to hardwiring devices or applications to each others’ physical internet location. This brings security at the high cost of maintenance and possibly reduced redundancy ( through lack of DNS load balancing ).
The predominant internet address “type” today is IPv4 addressing, the usual 4 byte address – like 10.243.14.2. The transition to a newer IPv6 address format is currently underway – or more accurately, the build up of a parallel internet which uses IPv6 addressing is underway. The IPv6 address is a 16byte construct – 4 times longer than the IPv4 address.
An IP address is effectively a topological address, or a geographic address in the internet v4 or v6 space. Like a postal address it is an indicator of location. Making an analogy to fixnet telecommunications, the IP address is the equivalent to a “geographic” phone number – the old PCM analog type – where each digit or set of digits brings the addressed payloads a bit closer to their final destination. In a mobile telecommunications context, the IP address has similarities to a Mobile phone’s IMSI, where the telephone number is actually a logical “name” ( albeit in the “phone” numbering scheme ) which the telco network looks up in a HLR ( analogy to DNS ) to find the IMSI and ultimately the mobile device’s position in the mobile network. With digital (including mobile) telephony, phone numbers have become names which some invisible telco internal DNS maps to some invisible address which routes calls to the physical phone equipment. Before smartphones came along, people had to remember phone numbers. At the best of times, 10 digit phone numbers were at the limit of what people could remember – maybe for one or two special numbers – parents, children etc. Also due to the continued use of “geographical” phone numbers even when digital switching was introduced – the “local area code” could be ignored – making most phone numbers to remember only 7 digits long. Todays smartphones and their contact applications like Whatsapp provide directory services ( aka DNS) from people’s names to phone numbers. People don’t have to remember any phonenumbers anymore.
My point is that the cost of not using DNS for security sensitive installations will increase with IPv6 due to the IP address length increase – because of the human factors which this brings with it. Nobody would ever be able to remember let alone type correctly a phonenumber of double length ( let alone 4x). An IPv6 address entered incorrectly into some configuration will need disproportionately more effort to recognize as incorrect because the address has less inherent meaning to the administrator. DNS itself is just as important as before in any case. Maybe DNSSEC will provide the solution.