Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?
In an all too familiar saga taking place in small-to-medium businesses (SMBs) everywhere, file/print, Web, e-mail, and application servers are multiplying at an alarming rate in response to ever-increasing demands for processing power. Initially, the decision to bolster capacity-constrained servers by adding more seems like a reasonable remedy for managing aggressive growth. However, when two-to-three additional servers grows to 10-to-20 over time while being provisioned for extra cycles to accommodate peak loads, this quick-fix solution mushrooms into a major IT problem, leading to accelerated operating costs, increasingly complex administration, and ineffective resource utilization.
The speil of most advocates for change in the server setup of SMEs (or SMBs or whatever you like to call small business) goes something like this: If you've got lots of little server boxes replace them with a smaller number of bigger boxes; if you've got a small number of bigger boxes replace them with a quasi-mainframe; vice versa; replace the one or more OSs you currently have with a single OS; and, by the way, our organisation just happens to sell the hardware/software/services that will make your migration path simple, trouble-free and expensive.
What such advocates fail to realize is that SMEs do not work that way. Small business does not have a coherent policy on anything except the following universal truth: We do not have any money to spare and if we did we certainly wouldn't spend it on ... . You fill in the blank with whatever is the subject of the proposed expenditure (IT is high on the list).
Furthermore, the "IT person (or department)" in an SME is very often someone who stupidly confided to management that he was "interested" in computers, or got volunteered for the job, or who didn't hear the question and, as a result, stood still when everyone else took one pace backward. These IT people are inadequately educated (they often have no training at all), inadequately supported and underfunded. They very often also have "proper" jobs with the company. They are struggling -- usually unsuccessfully -- to keep their heads above water. Trying to convince these IT personnel, or their superiors, that change (let alone additional expense) is good, or even desirable, is spitting into the wind.
Look at the range of activities that could be the subject of SMB server utilisation:
applications
files
data
web
mail
remote locations
road warriors
ordering, inventory, stock control
printing
fax
telephone answering machine
etc. etc. etc.
Just to add a layer of complexity, these various activities run the whole gamut from mission-critical, through 24/7 and periodically, to on-demand. They require administrative and operation permissions that range from "Touch this and I'll break your legs" to "Would the last to leave please turn off the lights".
It seems to me that advocates for change always argue a Microsoft answer to a problem that requires a Unix solution. A Microsoft solution requires masses of massive hardware all running an omnibus OS with hideously bloated applications: a Unix solution is to do one thing only but do it very well. You can always tell when a Microsoft solution is being proposed: a Microsoft solution always includes the words "more" "additional", "replace", or "purchase".
Why not consider a Unix solution?
Take the most overspec'ed server, by Unix standards, in the SME and load it with an absolute base install of your favourite Linux distro configured for Xen. Then load into a Xen chroot jail the particular Linux OS that suits your fancy configured to run only the application that used to run on this box. Make sure you give that application the appropriate access and permissions.
When you have that working, take the next most overspec'ed server box and use its hardware to supplement the Xen box, load into another chroot jail on your Xen box your next OS of choice (which may be the same or a different OS -- your call) configured to run only the application that used to run on the butchered box, dispose of butchered box (to Linux recycling charity if feasible).
for i in "list of server applications"; do {previous paragraph}; done.
Of course, the belt-and-braces brigade would heartbeat the Xen box using a High Availability distro. But that might require "more", additional", "replace" or "purchase" and will yield positive returns that can only be measured in time, money, personnel and sleep.
Why are there no advocates for the Unix solution? Because such a solution has no geek value and violates almost every Ferengi rule of acquisition.
But it will come.
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Just to add a layer of complexity, these various activities run the whole gamut from mission-critical, through 24/7 and periodically, to on-demand. They require administrative and operation permissions that range from "Touch this and I'll break your legs" to "Would the last to leave please turn off the lights". It seems to me that advocates for change always argue a Microsoft answer to a problem that requires a Unix solution. A Microsoft solution requires masses of massive hardware all running an omnibus OS with hideously bloated applications: a Unix solution is to do one thing only but do it very well. You can always tell when a Microsoft solution is being proposed: a Microsoft solution always includes the words "more" "additional", "replace", or "purchase". Why not consider a Unix solution? Take the most overspec'ed server, by Unix standards, in the SME and load it with an absolute base install of your favourite Linux distro configured for Xen. Then load into a Xen chroot jail the particular Linux OS that suits your fancy configured to run only the application that used to run on this box. Make sure you give that application the appropriate access and permissions. When you have that working, take the next most overspec'ed server box and use its hardware to supplement the Xen box, load into another chroot jail on your Xen box your next OS of choice (which may be the same or a different OS -- your call) configured to run only the application that used to run on the butchered box, dispose of butchered box (to Linux recycling charity if feasible). for i in "list of server applications"; do {previous paragraph}; done. Of course, the belt-and-braces brigade would heartbeat the Xen box using a High Availability distro. But that might require "more", additional", "replace" or "purchase" and will yield positive returns that can only be measured in time, money, personnel and sleep. Why are there no advocates for the Unix solution? Because such a solution has no geek value and violates almost every Ferengi rule of acquisition. But it will come.