Hacker News Reader

Don't get me started on chasing down NuGet dependency errors. The only difference is there's usually only one option for any given task. We're constantly held back by packages with conflicting references. I'm not jumping everything to Angular 2 just because it's available, but I can build my 1 apps in a fraction of the time it takes to use my old MVC boilerplate.

Seriously, good package management makes a huge difference. Long term maintainability really benefits from a package manager that you don't spend hours diagnosing obscure dependency errors. I do not miss this aspect of developing in C# at all, even if it was great otherwise.

>along with antivirus I've never heard of anyone seriously running antivirus on servers _except_ in the type of environments where it's mandated by terrible policies. Policies that probably aren't going to excuse lack of antivirus on Linux.

So yeah, if you're dealing with the type of person that runs antivirus, then everything else will probably suck.

I'm also confused what Windows has to do with an HA DB setup. Or do you mean compared to a cloud service, which has even more complexity, just hidden?

> So yeah, if you're dealing with the type of person that runs antivirus, then everything else will probably suck.

/shrug. I don't use Windows, but my understanding is it's fairly common including in server environments. I can't imagine taking money from people and storing their data on a Windows server without it having some kind of malware protection.

> I'm also confused what Windows has to do with an HA DB setup. Or do you mean compared to a cloud service, which has even more complexity, just hidden?

Well part of it is that SQL Server makes it tougher for a "boring stack for my personal projects" because it's pretty expensive if you want that. It just adds on to the "not boring" aspect of it. Admittedly my understanding is that there's nothing "boring" about a redundant relational database on Linux, either.

There are cloud services that help with this (some which manage that complexity, and others which abstract it away from you), but both of those options are probably more "boring" than maintaining your own SQL Server instance.

>I don't use Windows, but my understanding is it's fairly common including in server environments.

If you don't use Windows then its rather odd to opine about something you have no experience in. I guess we have a different view on the words "my understanding".

> I can't imagine taking money from people and storing their data on a Windows server without it having some kind of malware protection.

Okay, perhaps you can't imagine it, but again I don't quite see your point considering you don't even use Windows. I've been using Windows without an antivirus for over a decade without a problem. Maybe its recommended for non-technical users, but then again, as a server admin you hopefully know what you're doing.

>Well part of it is that SQL Server makes it tougher for a "boring stack for my personal projects" because it's pretty expensive if you want that.

SQL Server is free for developers. Also, IIRC SQL Express (also free) can be used for commercial apps.

> SQL Server is free for developers. Also, IIRC SQL Express (also free) can be used for commercial apps.

My response you quoted was in response to your statement about high availability, which is not included in SQL Server Express.

Ah, I see. I'd be curious to know what sort of personal project requires HA. But in any case SQL Server Developer edition (which has HA) is free.

The boring stack is just whatever is in your own comfort zone. I know plenty of people for whom SQL Server & C# are that comfort zone.

(FWIW mine is Ruby & Rails, and increasingly Elixir)

I'd suggest skipping servers and even containers and going directly to "serverless" with Azure Logic Apps.

Although my experience is with the AWS equivalent, me too--absolutely. Good luck keeping your comment visible here by suggesting "serverless" in a thread called "Happiness is a Boring Stack."

How much more boring could it be - a stack that is not a stack. Frankly, the only (and small, mind you) concern that I have with "serverless" is that it might make software development boring.

Yep. Agreed on all points. I sure hope software development doesn't get boring, but this'll be an interesting place if it does.

> I mean, that, as a minimum, means you're running and maintaining a Windows server, along with antivirus, backups for the OS, and backups for the database.

By contrast, if you're on the LAMP stack then you won't need a Linux box, and since you don't have a server you definitely won't need to secure it or back it up. It'll all just run on clouds or something, I guess.

No, the point is relative to being containerized, where you're deciding ahead of time what needs to be backed up (outside the container) and what doesn't. This leads to backups and restores being easier and more "boring."

It's also counter to one of themes of the post, which suggests by choosing this boring stack, he can just leave it alone for months at a time without touching it (presumably relative to other stacks). You can do that--but it's not like you're not still on duty for making sure these things are still working and happening.

EDIT: For clarity: You can set up a multi-AZ MySQL database instance on AWS, with whatever backup schedule you want, using a single API command. That is decidedly doing a lot of things under the hood, but I don't care--it gets done, and the backups get made to S3, and I don't have to handle it myself. It even (optionally) does minor updates for me and swaps masters automatically while doing them. To me, this is a great example of "boring."

Now compare that to setting up and maintaining something similar with SQL Server. It doesn't mean I don't have to secure or backup my MySQL database instance--it's just a whole lot more "boring" in the good way.

At least in the case of the database, I don't think I'd ever be willing to accept outside-the-container backups as a sufficient strategy. Not if I'm in a position to be held responsible for data loss, anyway. But that's me and my baggage.

That said, if you've got other reasons for wanting containerization, MS SQL Server can be containerized nowadays. Or you can choose a slightly different stack if you've got other reasons for wanting to not use MSSQL (cough cough price cough). Or you can shove it all into AWS or Azure or whatever and get on with your life, same as Linux. It's all good. Maybe the article's author is doing none of that, and that's fine too. Boring and old is a subjective thing, and has a lot to do with what you already know and have down cold. On the other side of that coin, it takes only a little bit of unfamiliarity to create and/or perceive something to be an unmanageable mess.

You can launch the same thing using SQL Server in AWS RDS as well, ditto the server itself. You can even do it with an Oracle DB if you so desire.

AWS is not just LAMP. Neither is Azure.

Yep. Sorry--my original point is getting derailed. I was responding to someone suggesting that it's ridiculous to take into account things like backups and security because those things are necessary on any platform.

The comparison was to illustrate that although those concepts exist on any platform, comparing the maintenance / backup / security of a database server you maintain yourself versus a managed instance shows significant differences.

Any stack has some headaches.

Right, but some stacks are better suited for tools that reduce or eliminate those headaches.

A Windows stack introduces hard requirements for some of those headaches.

If you're used to dealing with Windows they're not that big a deal and certainly less trouble than learning a new stack to avoid them.

Well, not really. Azure is pretty excellent and is free for basic apps.