Back in the day, I wasn’t a SNA expert but that was because almost no one was using it. Oh sure, SNA was used by all the big companies to connect their TN5250 terminals to their mainframes using SDLC but back in 1995 there A) weren’t that many companies who could afford to operate a mainframe and B) a mainframe didn’t actually do all that much other than accounting and warehousing.
SNA Was Well Designed
As a nerd, SNA was a thing of beauty. Each layer of abstraction was clearly defined, functions separated, physical and logical nodes clearly defined. For each interaction between nodes there was a separate protocol, defined and documented. But SNA was doing a very simple thing – allowing mainframes to communicate to text-only printers & terminals.
SNA Was Truly Awful To use
My recollection of IBM Systems Network Architecture (SNA) is quite vague and hazy these days. That iss deliberate because SNA was a pile of crap and I couldn’t wait to forget it.
It was so complex & difficult to actually use that TCP/IP was massively preferred because TPC/IP actually worked, could be understood by normal humans with a limited amount of training and, importantly, cost a reasonable amount of money. TCP/IP wasn’t quite as reliable on low-bandwidth links, IP Routers were not cheap back then (and, lets face it, still aren’t today) but it was good enough. Cheap & Good Enough always wins.
Check out this Wikipedia article just in case you forgot how painful it was:
- Connection to non-SNA networks was difficult. An application which needed access to some communication scheme, which was not supported in the current version of SNA, faced obstacles.
SNA network installation and maintenance is complicated and SNA network products are (or were) expensive.
- A sheaf of alternate pathways between every pair of nodes in a network had to be predesigned and stored centrally. Choice among these pathways by SNA was rigid and did not take advantage of current link loads for optimum speed.
- SNA’s connection based architecture invoked huge state machine logic to keep track of everything. APPN added a new dimension to state logic with its concept of differing node types. While it was solid when everything was running correctly, there was still a need for manual intervention.
To make matters worse, very few companies could innovate on IBM SNA because everything MUST be defined. IBM retained control over defining what was allowed and stifled innovation completely.
Ok. I will stop here. You get the idea. TCP/IP has problems but you don’t have to pay to have them. SNA was expensive, inflexible, complex, and was a closed standard.
Lessons to Learn
There are number of possible lessons to learn from the failure of SNA. Let me take a stab at some of them to kick things off:
- No one wants to pay for networking. Users want to access their applications, but the network is a toll road to get there. When the toll is too high, people don’t use the toll road.
- Complexity in networking architectures is FAIL.
- Rigid and closed standards in networking FAIL.
The EtherealMind View
Some people look back at SNA fondly and that, more or less, is normal. Everyone eulogises a dead family member as a gesture of respect for their memory but SNA was the family member you absolutely hated and, secretly, everyone were quite pleased when it died.
SDN and SNA are about as similar Model T Ford & any modern car. For the record, no drives a Model T Ford to work everyday.
Stop comparing SDN to SNA. Its pointless.