Zomg! Routed Deployments?

So I was bored out of my mind on the Acela last night and started reading the OpenDeploy 6.1.1 configuration guide. There's this interesting feature described around page #97 called "routed deployments." Has anyone ever used that? What for?

Find more posts tagged with

Comments

nipper

From the product guide:

Routing adapter: The new routed deployments feature relies on an adapter for computing multi-tiered delivery routes for deployed files. The default adapter employs a "first match" algorithm for dynamically constructing routes from a configured list of possible route segments.

BTW, you seriously need a life.

Tbag

Yes, yes I do.

I'm trying to imagine a business case where this is really necessary, but I keep coming back to thinking maybe this was some IWOV developer working on their CS Master's thesis and got carried away ;-)

nipper

It is not that hard to imagine, there are IWOV customers that have several hundred and even thousands of receivers on a single deployment (IIRC, the largest I ever heard of was about 5,000). I expect you can spend a great deal of time trying to figure out what the proper routing structure would be in that case.

This was very likely a request from one of those customers.

Andy

Adam Stoller

Yes, yes I do.

I'm trying to imagine a business case where this is really necessary, but I keep coming back to thinking maybe this was some IWOV developer working on their CS Master's thesis and got carried away ;-)

Allow me to enlighten you ... as I was the original author of routed deployments (done with Perl DNR scripts).

The company I designed it for (back in 1999/2000) had major farms of web servers in diverse locations (several in the US, Asia, Europe, etc.) and the problem was how to deploy content from any source TeamSite server to all the target receivers in an efficient manner.

The solution was to use the WAN sparingly - by sending the content across the WAN to a "hub" (another OD Base Server) along with the information necessary to deploy the same files from the "hub" to the next location (which could be another "hub" or an end-target receiver) so that eventually you get to a "hub" that is local to the receivers and then perform a fan-out deployment.

Thus deploying 100 files to 100 receivers could consist of a fan-out to 4 hubs (in geographically distinct locations) followed by each of those hub's performing a fan-out deployment to 25 receivers that are all on the same LAN. Far more efficient than deploying the 100 files point-to-point over the WAN to 100 receivers.

The routing code was initially productized in OD 5.5.1 - and then re-vamped later to be more "intelligent" (the old system required a series of hard-coded "maps" be distributed to all the hubs so that they could figure out what to do next -- I believe the new system obviates the need for that).

Unfortunately, I haven't had the need / opportunity to try using it since the initial Perl / DNR version -- so I cannot provide any anecdotes about the current version.

These days there are other ways of handling the fan-out aspect (shared mount points on NAS devices for example) such that a single fan-out to what would otherwise have been hubs might suffice -- though those provide a single-point-of-failure issue if the NAS has problems - whereas the hub-fan-out to individual receivers allows those receivers to be load-balanced and if any of them go down the others can still provide service.

Of course that still leaves the "hub" as a potential single-point of failure - and I think this is where the new "intelligence" plays a significant role - in that I believe it can [more] dynamically determine the route from point A to Z even if some nodes along the way are temporarily down.

Frankly I'd love to hear about anyone's experience with using the current version - even though it's not my original code, I still take pride in having developed the original working model.