Date: Tue, 26 Jun 2001 18:37:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@FreeBSD-uk.eu.org (j mckitrick) Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD and the shift to 'web services' Message-ID: <200106261838.LAA28998@usr05.primenet.com> In-Reply-To: <20010626152623.B78438@dogma.freebsd-uk.eu.org> from "j mckitrick" at Jun 26, 2001 03:26:23 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> It seems that much of the business world is heading toward selling software > as a service, or, more importantly, making services available to local > applications. > > Can Unix in general fit into this plan? Obviously Sun, IBM and others have > alternatives to the Microsoft plan, but will open source be able to get > involved? Does FreeBSD need to consider this, or is it a layer above the > OS, like Java, XML, Perl, etc, which already exist? What about a Common > Runtime Library for FreeBSD, so it can act as a .NET server, if and ONLY if > the concept takes off? It's a "last mile" problem. As network links become faster, it makes sense to outsource some infrastructure components. This permits you to have ubiquitous access to your data, regardless of where you are accessing from. One thing I really hate about the dialup ISP convergence to a few providers is that it is occuring before the local small ISP's were able to build out their "last mile" infrastructure. This means that it will probably be a long time before we see final completion of the "last mile" sufficient to host all software services. Another thing I hate about it is that it's becoming harder, not easier, to obtain ubiquitous access to your data. The premiere example of this is email; email is the "killer application" for the Internet: it's point-to-point, human-to-human communication, and that's what humans want, above all else. No one expected the telephone system to turn out the way it has, and, likewise, no one expected the post office to turn out how it has. Cell phones have grown at an incredible rate, while all the "content" that people intended to push down cell phone lines has failed to find willing buyers. In the United States last yesr, people spent as much on telephone calls to other people -- more than a quarter of a trillion dollars -- than the U.S. Government spent on all defense spending, combined. Most of the "converged" ISP's currently out there today offer SMTP relay, a POP3 maildrop, DNS forwarding, and maybe access to an NNTP server, and some other not-very-useful "services", like the ability to have a small home page hosted on their servers (this is generally intended as a loss-leader for up-sell to more hosting services at a later date). This is woefully inadequate: the POP3 protocol was not designed to operate in such a way as to permit multipoint access: once you download your mail, it's stuck at whatever access point you downloaded to at the time, and leaving the mail on a POP3 server is not an adequate answer, any more than keeping a copy of it on your work system -- thus opening your private email to legally permitted monitoring of content -- is adequate... or reasonable. Systems like HotMail fail to address a lot of basic issues. If you read the terms of service oon HotMail, even if you are paying them for their "premium" service, they have no obligation to not drop the email on the floor. This is unsurprising: they do not commit the email to stable storage before acknowledging it to the sender via the "250 Accepted for delivery" SMTP response to the correct termination of a "DATA" command. Instead, the mail ends up in a RamDisk, and you had better hope the power does not fail on that single system. What this means is that, while it's a good idea in many cases to want to outsource certain infrastructure components, even the most basic, minimal service which you _must_ have to be considered to be "on the Internet" -- email service -- isn't really safely outsourceable with the current infrastructure. You would _never_ bet your business on HotMail, or OneBox, or BigMailBox, or Yahoo Mail (formerly RocketMail), etc.. Until these services can achieve the reliability of the telehone, and that includes your link into the service provider, they are not capable of replacing on-site business infrastucture. Some products address these issues. I have a (currently on hold) set of software that takes a first stab at the email problems, and, I think, does a sufficient job of addressing them... but not to the extent of being able to make "the last mile" reliable. With redundancy (e.g. a dialup to ensure that, should you lose your DSL, you can still get in and get your email), if there are telephone-level-reliability guarantees to the service, then it may even make sense in the face of a "last mile" outage to outsource: at least your mailbox will be reachable to your customers, when a "last mile" outage would in fact otherwise render you "off the net" with a local server. It may even be that, with continued power problems, this would become a preferred model. But there are other business barriers which you would have to overcome, apart from the reliability and trust angles. Should ".NET" become a reality, then it will be no time at all before it is reengineered in Open Source. The components are already there (Xerces, or XML4C++ from IBM's "AlphWorks", and other "glue code" is trivial to write to obtain the minimal required functionality). Companies will not win based on closed standards -- we learned that during the Cold War, and we're not going to make the same mistake again, when it comes to our critical infrastructure. I personally think that it's very unlikely that people wll trust Microsoft, or any single vendor with their data. That approach to getting ubiquitous access will fail, without strong cryptographic guarantees on the privacy of your data, and its inaccessability to other -- including the hosting service. It will be a long time before Sun's "The Network IS The Computer" can turn into Microsoft's "The Network Is The Storage Device". All IMO, of course. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106261838.LAA28998>