Thursday, July 14, 2005
Service Discovery in the Enterprise
So here's an interesting problem. Suppose you're working on a distributed software management tool, and you want to be able to know what component is where, so your interconnected components survive things like IP address changes with DHCP, and so you can make things easy for the user to install.
Service discovery would be really handy, don't you think? After all, the user wouldn't have to configure eight million things: they'd just need to drop the component (software, appliance, etc) onto the network, and it could reach out and figure out who else was there. You may need to have the installer take some sort of password or other credentials (to minimize hacking), but otherwise, just plug and play.
And with IP multicasting, a simple service discovery mechanism for your software is pretty much a snap. Of course you'll need to come up with some sort of "bridging" mechanism to bridge islands of components on various local LANs across your corporate WAN, but that's a matter of configuring--letting one LAN component know where another LAN component that is not "discoverable" is located. This is far easier than having to configure every God-damned tool.
And designing such a thing is fairly simple: first, go out and look up some of the existing protocols, such as the zeroconf protocol that Apple has been pushing. It's good to know what sorts of things people are doing. And what Apple is doing is creating a protocol where box 'A' says "who out there has 'foo'", to which boxes B and C say "I do." Of course for our purposes we may want to do something slightly different from Apple: we have specific problems we need to solve that may not quite work with Apple's protocol.
But there is something odd out in Enterprise software. For some reason or another, "ease of use" often still gets equated with "toy operating system"--even though service discovery is a lot more effort (especially with Enterprise, where there are additional security requirements) than simply prompting the user with a bunch of badly designed dialog boxes and having the poor user put all of his managed boxes on fixed IP addresses.
What is with that?
At times I have to wonder if Enterprise software developers fall into two groups: those who are working very hard to solve hard problems--such as building transaction processor engines which no-one but a handful of experts get. Then you have the folks who hook all this stuff together, to whom "automatic configuration" is somehow a "toy", yet whose idea of useable design involves giving the user a bunch of command-line tools because they couldn't think the design of their architecture.
Ease of use is not something you tack on; it's something you design bottom-up. But for some reason or another, "ease of use" is something most Enterprise people try to tack on at the end because they don't understand it at all. Because "ease of use" is for toy operating systems, not for "serious" people... ¶ 3:32 PM
Service discovery would be really handy, don't you think? After all, the user wouldn't have to configure eight million things: they'd just need to drop the component (software, appliance, etc) onto the network, and it could reach out and figure out who else was there. You may need to have the installer take some sort of password or other credentials (to minimize hacking), but otherwise, just plug and play.
And with IP multicasting, a simple service discovery mechanism for your software is pretty much a snap. Of course you'll need to come up with some sort of "bridging" mechanism to bridge islands of components on various local LANs across your corporate WAN, but that's a matter of configuring--letting one LAN component know where another LAN component that is not "discoverable" is located. This is far easier than having to configure every God-damned tool.
And designing such a thing is fairly simple: first, go out and look up some of the existing protocols, such as the zeroconf protocol that Apple has been pushing. It's good to know what sorts of things people are doing. And what Apple is doing is creating a protocol where box 'A' says "who out there has 'foo'", to which boxes B and C say "I do." Of course for our purposes we may want to do something slightly different from Apple: we have specific problems we need to solve that may not quite work with Apple's protocol.
But there is something odd out in Enterprise software. For some reason or another, "ease of use" often still gets equated with "toy operating system"--even though service discovery is a lot more effort (especially with Enterprise, where there are additional security requirements) than simply prompting the user with a bunch of badly designed dialog boxes and having the poor user put all of his managed boxes on fixed IP addresses.
What is with that?
At times I have to wonder if Enterprise software developers fall into two groups: those who are working very hard to solve hard problems--such as building transaction processor engines which no-one but a handful of experts get. Then you have the folks who hook all this stuff together, to whom "automatic configuration" is somehow a "toy", yet whose idea of useable design involves giving the user a bunch of command-line tools because they couldn't think the design of their architecture.
Ease of use is not something you tack on; it's something you design bottom-up. But for some reason or another, "ease of use" is something most Enterprise people try to tack on at the end because they don't understand it at all. Because "ease of use" is for toy operating systems, not for "serious" people... ¶ 3:32 PM
