In reference to this article on Cisco's Fog play...
Latency and bandwidth issues are often pointed to as reasons to adopt fog, but I could see Fog being adopted even when latency and bandwidth are not the issue.
Have not seen anyone factor in:
1) Local autonomy in the face of WAN failures e.g. where getting a response is ultra-critical (e.g. medical, safety systems of almost any sort).
2) New applications that could become possible with software running inside the network pathway and having access to SDN and other aspects of network vritualization
3) Peer-to-Peer possibilities (as in, no need for central cloud hosting service like AWS or Azure, at all in the remote future)
The overhead of these fog computing enabled devices closer to the user does not necessarily mean that much additional overhead. They are thinking about how things are now. If a company still needs to connect a LAN, they already have devices to be maintained, and if those same devices are fog enabled, it is not that much more complexity (especially if they are cloud managed).
If Amazon and Azure push parts of their stack down or Cisco can get the software right in terms of seamlessly fitting into public cloud stacks, entire new applications will come out of this.
One other aspect is getting the fog layer to be in the telecom connection points along the 4G/5G path close to the edge.
Given the need for good tooling and software, I don't see Cisco winning on this in the long run. Would bet more on Amazon, Microsoft, Google, and possibly even IBM.
Longer term, the possibility of P2P being applied at the Fog layer could ultimately be the undoing of AWS and Azure.
