6 ms·
Windows... On a server? interesting
by bwbw223 9y ago
Windows... On a server? interesting
- EpicEng 9y agoI am forced to host many of our services on Windows machines at work. I can attest there is nothing 'interesting' about it :)
- ZenoArrow 9y agoIt's not what GP was referring to, but... https://en.wikipedia.org/wiki/Windows_Server https://en.wikipedia.org/wiki/Windows_Server
- scarface74 9y agoNot what I was originally referring to, but yes at work our entire system is 30+ Windows Servers running C# programs and services using Consul, Nomad, Mongo, Sql Server, and Memcached. Continuous integration and deployment is all done with Microsoft agents orchestrated by VSTS (Microsoft's hosted version of TFS). Yes we use git Easy to maintain and no performance issues.
- OkGoDoIt 9y agoI wish more people in the bay area understood that Microsoft has a really awesome development and server ecosystem.
- scarface74 9y agoI came into a midsized company as the dev lead with no real development shop with free reign, a decent budget, and management support to build the department the way I saw fit. I had never used VSTS and had heard nothing but bad things about TFS. They already had it and I decided to play around with it. I was amazed how easy it was to create a CI/CD environment that followed generally accepted best dev ops practices.
- CydeWeys 9y agoWindows is the second most widely used server operating system in the world, second only to Linux. It's pervasive in companies outside of the tech industry, to give one example of typical usage. Linux and Windows together dominate this market so thoroughly that everything else (UNIXes, BSDs, macOS) is practically a rounding error.
- pjc50 9y agoIf you want to serve files to Windows machines and you don't mind the license and painful remote administration, it's a reasonable choice. Guaranteed SMB compatibility.
- scarface74 9y agoHow is remote administration painful? All 30+ servers I run have VSTS agents. I can do most administration by running Powershell scripts and choosing the deployment groups based on the purpose of the server. I have Consul agents for health checks, Consul watches for alerting and/or automatic recovery, Nomad for running executables across the app servers, HashiUi for monitoring and controlling the Nomad pool. I can approve and deploy a release from my iPad (the website is painful on my phone) by logging into Microsoft's Visual Studio Team Services website. I won't even start to gush about how easy setting up a build and release pipeline is in VSTS compared to the other tools I've used.
- dfox 9y agoIt is painful in the mindset of typical unix guy who is used to being able to "just ssh somewhere and vi /etc/something", which is not the way you want to manage large deployments but works even for large-ish ones. On windows there is no real middle ground between use GUI for everything and automate everything. Also with unix servers various bastion hosts and similar "security measures" are minor inconvenience and usually even supported by automation tools, while on windows this usually ends up being major PITA.
- scarface74 9y agoThe biggest pain for Windows remote automation is security around accessing servers remotely, I'll grant you that. I gave up. That's why I have VSTS agents on every box. I can easily write a script and tell each agent to pull the script down and do X locally and insert the results if needed into a Mongo collection. But for the few times I do need to treat my servers like "pets" instead of "cattle". I do everything from the GUI. There was a time when our net ops team did something and I couldn't Remote Desktop into a server to do something urgent and if course I couldn't just SSH into it where I had to write a quick Powershell script and deploy it via VSTS to make a change. It was ugly.