It sounds wrong to me to refer to Apache and nginx as "alternatives" to IIS. They're the web servers, and IIS is the "alternative", kind of like how Excel is the spreadsheet application and LibreOffice Calc is the alternative. I'm aware that I cocoon myself in something of an anti-Microsoft echo chamber, though. Does reality match up to my prejudices?

> Does reality match up to my prejudices?

According to the linked article, IIS has only 16% market share overall, and less than 11% of the top 1000 websites, so I'd say yes.

At the risk of second guessing the parent, they're considering the classical 'enterprisey' stuff as mainstream. If you look at what people use in most companies of a reasonable size, IIS is surprisingly common and Apache tends to only turn up when Java or PHP is involved, with appropriate nods to Oracle and IBM for their relative technologies.

Outside on the open Internet I absolutely agree that Apache and Nginx are the default HTTP servers. I switched from Apache to Nginx years ago (with a few exceptions) as it just seemed as though I could do more with less with it and it made sense for me to standardise.

I see nginx as more a general application server, and IIS as a specialised server you run when you need NTLM/Windows integrated authentication and ASP.NET et al.

> Does reality match up to my prejudices?

Similar to how Apple takes ~75% of the handset market profits, IIS takes almost all the profit in the web server market and is increasing revenues year after year.

It does quite well for itself given that the competition is fierce and free.

By this logic, Adobe ColdFusion is taking the majority of the profits in the dynamic web language space.

Yes and?

If you apply a set of criteria then that is the result.

The more interesting metric (though hard to quantify) is how much is earned with software.

I don't think that's accurate. Do you have a reference?

http://www.zdnet.com/blog/stewart/adobes-q1-financials-show-...

I would think ASP.NET/C# would make the most profits in the dynamic web language space.

I guess I still think of C# as typed.

My point being that CF has a license, whereas Ruby and Python do not - which has little value in gauging success, a la IIS v Apache/nginx. (Ignoring the reality of open source Railo and Open BlueDragon for the moment)

Ruby and Python are strongly typed, but they're also dynamically typed. Certainly not untyped.

They also both have licenses, but they don't charge money to obtain a copy.

Not to be pedantic, but I suppose you mean license as "you have to pay to use it". Both Apache and nginx have a (free software) licence.

Yes, I meant "paid license" :-)

My rule of thumb for OSS software is that if a type of software is integral to developers' jobs, then there are some very good tools available. Operating systems, web servers, text editors, database systems, ... are all good examples of this. If the type of software is not integral to developers' jobs, then there are fewer good alternatives. There are some pretty good ones (OpenOffice, GIMP), but they're often not as polished and lack power features.

I've always found it interesting that of the major Web servers IIS is the only one with a programmatic configuration API.

generating and modifying unix config files programmatically has been happening for nearly half a century

the only reason a web daemon has an API in windows is because the windows registry is opaque, error-prone and in general, a giant piece of shit.

IIS configurations are stored in web.config and other XML files that are easily editable.

Nothing easy about editing a couple thousand line xml file. Especially when it's on the server and you have to do it with notepad.

It being on the server precludes opening an IDE?

That said, I agree that it would be better if it isn't a thousand lines, and maybe there are better options than XML.

The company I work for is a Microsoft shop (for now, switching to Java sadly), and I've edited a lot of web.configs in servers, sometimes using Notepad, and it wasn't much of a hassle (though I did have to research what to edit beforehand in some cases).

You have IDEs installed on your production servers...?

My comment was refuting the parent's comment that IIS needed a GUI because it used the Windows Registry to store configuration information.

Which is why IIS has a GUI tool to do it, and with .NET you can edit the configuration with a few lines of code.

Yes, because the registry is terrible. If the registry were any good, IIS configuration would use it, and you'd be able to programmatically reconfigure IIS, or any other program, in a standard registry-based way.

I have never configured an IIS server. Do you find that the programmatic configuration API is helpful? I rarely find httpd.conf or nginx.conf to be difficult to manage, but it's possible that we're missing out on a good thing in the OSS world. It's been known to happen.

I built a system that generated IIS configuration XML files, and a script to apply/import them on any/all servers in an array. It worked, and was substantially better than using the supplied GUI, but still inferior to editing nginx conf files by hand. These days I wouldn't touch IIS with a [very long object].

IIS 7.5 / 8 is pretty good. Some cool features in 8.

Anything below 7.5 I hope I never have to touch again...

Instead of killing worker processes that exceed the CPU throttle, like in IIS 7, those processes are simply throttled in IIS 8.

I use jinja templates to generate nginx config files. I don't need yet another proprietary API with its own quirks and interoperability problems.

Have you looked at Auegas? I've used it quite a lot from within puppet to make well-structured changes to Apache config files.

That's Augeas. ( http://augeas.net/ ) It takes some getting used to (some files are much easier to manage with plain old sed), but it's quite a cool and useful tool. Puppet and Kickstart are good use cases.

Does a shell/python script that writes a httpd.conf file count as a configuration API?

I think so...IIS 8 can be auto-configured in several scripting languages, including powershell, c#, etc.

I think it reflects the general Microsoft philosophy of having APIs for everything. After all, they are an API company. It shows in the PowerShell design with it's object API approach.

Also, with the API you should be able to configure IIS without restarting it, while changing web.config recycles web apps (in ASP.NET scenario). With load-balancing, however, this is less of an issue.

Simple text parsing + service restart obviates the need for an API. The shell is your API.