[div0]

If a task involves "clicking next", then that task should not require any specialized knowledge to do. I totally agree that all developers should be willing do write code to automate "DevOps" tasks whenever they see fit. I know a lot of programmers who do this. These programmers always have a bunch of scripts sitting in their ~/bin, and you hardly ever see them clicking. I am a "programmer", but I love "DevOps" stuff, and mostly recently I wrote a large automation framework that got CI team interested. Tons of energy and time is wasted everyday where teams don't understand (and don't want to understand) each other's code.

[teh_klev]

> If a task involves "clicking next", then that task should not require any specialized knowledge to do

I would disagree with this point. If you're installing anything on a production box you really should know what that installer is going to do to your environment. Have you walked through the MS SQL Server installer wizard? You absolutely do need specialised knowledge if you're running that on a client's server.

[MichaelGG]

SQL Server is probably one of the easiest "big" software systems available in the world. Without having much specialized knowledge you can setup a powerful HA cluster. It's mostly clicking next and following some basic instructions. Out of the box, it'll perform pretty well (just remember to click the "Optimize for Ad Hoc Workloads" checkbox in the properties page).

SQL Server requires vastly less "specialized knowledge" than, say, Postgres. I would be surprised to find that most SQL Server installs come with someone with really in-depth knowledge.

The same applies to a lot of other things MS ships, like setting up AD. Sure, knowing what you're doing helps, but MS sorta built an empire on making a lot of that stuff pretty trivial to do. For another example, look at setting up IPSec. A cute little UI you click on, versus well, the process on Linux.

[teh_klev]

Sorry no, it's an easy clicky pointy path to hell when you discover one month later no-one understood what the file path options meant (and there can be many when installing Standard+) and then the system volume ran out of space.

Or what accounts to run SQL's various services under and wonder why stuff doesn't work or their SQL box gets hijacked ("oh I'll just run this under the SYSTEM account").

The install wizard for SQL Server 2008R2 Standard Edition has around 20 pages (counting tabs on a page) of user selectable options and settings. You certainly do need to know what you're doing and understand the implications of each every one of those settings.

Sure if you're just doing a quicky install of the Dev Edition on your workstation you can afford to be a bit lax and click on through, but on a mission critical production box you need to RTFM or let a SQL admin who knows what they're doing perform the install.

I've been called in too many times to unf*ck a SQL server because a customer has declined one hour of installation support because their devs thought they knew better.... "oh yeah it's just clicky pointy install, why do I need help with that". Trust me GUI installers do not equate to "easy install" if you have no clue what the installer is asking you.

I'm a SQL (MS and MySQL) admin, amongst many other roles, for a webhoster with 19 years MS SQL Server experience (started on SQL 6.5 in '97), been there seen it all.

[MichaelGG]

I mean, if you consider knowing that databases require disk space to be "specialized knowledge" then, I mean, I guess so. Otherwise the installer is rather straightforward in telling you what the paths are for. And creating a new DB also shows you which files will be used. There may be 20 pages, but most of that is ... pretty straightforward, easy stuff.

I've run SQL Server in life-critical production systems (911 call routing) and found it to be very straightforward. Just make sure the alarms are turned on and enabled for replication.

I've run it in HA clusters, both with a shared DAS and with the new shared-nothing system. A walk in the park. The only difficult thing I've personally run into with SQL Server was figuring out the Broker Service stuff and dealing with replication outside of a domain. And that was probably mostly networking configuration issues - the config wizards are pretty amazing.

I'm not implying that there is no specialized knowledge, and many SQL Server installs are probably suboptimal. But it's far from necessary to know much to go very far with SQL Server.

Compare to Postgres, where doing anything correctly requires mucking around with the config file, and, last time I used it, logging into the shell with a special user. And HA, well, good luck.

[BuckRogers]

Sounds like you both came to the conclusion that to do things it's best if you pay attention and care.

I may be the only one around though that doesn't find config files to be 'mucking' or a form of mysticism that all should kneel before the user who can wade through them. That also, is not 'specialized knowledge'.

[collyw]

I managed to install Postgres from source, and have a standard setup. It wasn't so bad. Run the usual configure make, make install scripts, and go through a tutorial page for setting up the initial user. Ok, I have a fair bit of Linux experience but I am not a sysadmin.