We were discussing the proposed Energy Market Information Exchange (EMIE) Technical Committee last week when a participant asked "What’s wrong with having devices communicate in their own native languages and over their most optimal media?"
At its heart, this query is a request to let first costs equipment trump all other concerns. It ignores cost of ownership. It ignores the costs of security. It even ignores initial integration costs. It is a naïve plea for a simpler world.
When they were young, I remember my children regularly escaping after the evening bath and scampering through the house. As we’d capture them to stuff them into their warm winter pajamas, we’d hear the joyous plea "Want to run around naked!" It was a happy request, one that always made me smile.In my, uhmm, mature and fully deployed state, few would be as charmed if I made the same request.
Look, I don’t care if you and your family walk around naked in your house. When you go on the street, and expect to interact with others, then societal expectations for behavior and dress kick in. I don’t care if you create small naturist clubs where you can walk around naked with a larger group. Every naturist camp always has a sign by the door "Did you remember to put on clothes?" Streaking, though, is always disruptive. As someone who has managed any number of "native protocols" interacting on a campus backbone, I know that those are far more disruptive then the kids who streak the library each semester before exams.
Tunneling protocols over IP is the like late night explicit romantic phone call. It may be an expedient solution to a short term problem in a niche situation, but it is no architecture. Such phone calls have their own protocol, and their own semantic choices. If that same communication style extends to other phone calls, you get social problems, and potential law suits. Tunneling protocols, xxxx over IP, are just as problematic. They are barriers to interoperability. They don’t recognize external costs. I have seen dozens of high-dollar man hours expended to avoid a second $500 gateway. I’ve seen larger numbers of man hours expended again and again by network operations staff to sustain the protections that these tunneled protocols need.
Based on experience and battle scars, here are a few principles that *I* hold dear:
- Anything that can be attached to the internet, will be. This means that it will be exposed to unanticipated protocols, hostile interactions, and even accidental DOS attacks. We should define interfaces to systems accordingly.
- Systems should be small and coherent, and should not have the internet in the middle.
- If the internet is in the middle, or perhaps even if IP is in the middle, what you have is two systems, and you should treat it as such.
- Internal "native" protocols should not be used to communicate between systems.
- The communication stack at the edge of a system should be well tested and well debugged, and have been used in as many open scenarios as possible so that all exceptionalism will have been eliminated. I never want to discover a new "unanticipated interaction"
- When any combination of systems gets to a sufficient size, interoperability (or the lack thereof) becomes the most significant determinant of expense.
- In any significant system integration, you will be unable to prevent diversity. (Every now and then, someone asks me "Wouldn’t it be easier if we just picked one vendor, one brand, and..." I point out that if we did that, it would take us 20 years to get the "one true protocol" installed, and by that time, we would be unable to buy the legacy systems any more.)
At the edge of each system, we should have well defined discoverable interfaces. There will be circumstances, few and rare, in which we legitimately need to split a system in half<—>but not many. There will always be a need for tunneled protocols, just as there will always be those late night phone calls. We rely on them when we must, but are fooling ourselves if we rely on either one by design.
System providers should always ask these questions.
- What is the interoperability requirement?
- Do you want the integration to scale?
- Will one integrator be responsible for all systems, and all systems that interact with them?
- Over time, will the system ever interact with additional systems?
- Will there ever be any new security requirements.
Answer all five questions. Ask yourself how you define system. Consider whether you are able accurately to predict the changes that will occur in the internet over the life of the system, which may be 20 years? Then, and only then, is it time to consider the justification of the native protocol outside the core system. Then consider if you would be willing to put *that* full explanation into your sales literature...
As your systems mature, as they begin interacting with others, don't let them run around naked.