× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Mon, Dec 1, 2008 at 04:26, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
Ouch. That's my first time to be accused of FUD on a mailing list. I thought it was CW [conventional wisdom] that complex workloads destabilized Windows ;-)

Don't take it too hard. I'm the sole Windows fanboy on this list ;)

You make a good point about an application like Facebook, which is mostly static content for millions of users. There's no pressing need for a centralized application / database server for static content.

Actually, facebook needs both. While there's lots of static content,
there is also lots of dynamic content.

You handle a lot more users with minimal footprint, and without increasing your operations staff.

Think about Facebook again: You have thousands of concurrent users -
the measly 64 CPUs with maybe 4 cores each are nowhere near the
processing capacity required for peak workloads. Web applications like
Facebook are massive in scale. And cost is another factor: If you need
64 quadcores on Intel/AMD base, we're talking about maybe 250'000 US$
- a 595 on the other hand. Of course, the hardware quality can't be
compared in such a case, there's no doubt about it.

Another thing to think about: What good is a 64 socket server in the
US when 1/3 of your users is in Europe?

Contrast that with an application like Microsoft Dynamics CRM. I recall an expert recommending a minimum of 5 servers in a typical deployment, with each server performing a discrete role.

Yes, this is a generally different approach. And as you can see, as
CPU power has massively increased in the past few years,
virtualization is a big hit in the Windows world, as it allows several
applications to run on the same hardware.

Now i'll try to explain why CRM does what it does - i don't expect you
to agree with it, but maybe see that the system wasn't designed by
drooling morons ;)

Never used Dynamics CRM, but i just downloaded the deployment guide -
it recommends a five server minimum configuration:

2 Domain Controllers
1 Exchange Server
1 CRM App Server
1 CRM SQL Server

Okay, first things first: Domain Controllers are for centralized
authentication in a Windows network. They store highly secure data
like passwords, users and their group memberships. Domain Controllers
achieve redundancy by using a multi-master replication model. DCs are
extremely critical components in a Windows network - if all your DCs
are down, nothing will work.

Which is why DCs are designed to be redundant. But it's not like you
have to buy two separate new DCs just to run MS CRM - two DCs are a
standard deployment best practice as soon as you have 50+ users, and
you can reuse the ones you already have for your MS CRM deployment.

Exchange is a Groupware - if you're already using Exchange (which
would be the assumption if you plan to deploy MS CRM), you already an
Exchange server - it's not like you have to buy a seperate Exchange
server just to MS CRM.

CRM App / CRM SQL Server: These are the two servers you might need to
purchase or provision as new VMs. It is usual for smaller companies to
consolidate their SQL Server instances into one bigger machines, so
depending on the setup you have you might only need the application
server.

So, you only need 5 servers for a green-field deployment. For a
preexisting Windows environment, you might need 3, 2 or 1 servers,
depending on what is already there.

The reason for the one-app one-server policy is simple: too many
idiotic 3rd party ISVs. You'll also see bigger i deployment using
LPARs to segregate different applications (for example, a Lotus Notes
LPAR), though of course that's nowhere near to server sprawl you might
see in a Windows Deployment.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.