So we’re building an Internet service not a Web service, decide on an address, allocate a port, write our daemon (yes, I like Unix) job done. One might think so but there’s a killer deployment issue lurking in the background - the Firewall.
The average corporate security policy really doesn’t like opening ports on external firewalls (and often the same goes for internal ones). Best case we’ll have to wade through masses of red tape, worst case we’ll be given a flat no to our request for an open port. What to do?
Find an open port, find a way to tunnel through it. Which is the port most likely to be open? 80 and we all know which protocol runs over that. Sure as night follows day, we end up building a solution that tunnels over http.
Do we want to be “of the web”? No.
Would we by desire tunnel over http? No. It’s not designed for that purpose and it’ll likely let us know come implementation time.
Should we re-design our service to fit with ROA? No. Hopefully we did the research and looked at this option before choosing to implement an Internet service as opposed to a Web service.
So Internet and Web services are different but can end up looking similar enough to lead to confusion. Ain’t reality ugly? Tradeoffs must be made, the results are often less than pretty and there might well be a lot of complaining.
Technorati Tags: architecture, networks, systems
Entries (RSS)
November 2nd, 2007 at 11:18 pm
This stuff makes me crazy.
The firewall people just end up making port 80 be a giant backdoor. If they’d allow you to set up a separate port, the traffic to your daemon would be separated out. Easier to monitor, easier to control, easier to slam the door on if Bad Things Happen.
Instead, they force you to add your traffic to the port 80 mess. Now your traffic is almost indistinguishable from anyone else’s, and if the security folks decide that they need to block your traffic - they can’t.