BRRABill's Field Report With XenServer
-
prepares to move to the moon
I don't understand the resistance to using the GUI in Windows... the RSAT tools are a GUI themselves, whether they are run remotely, or from the server's console (or over RDP) is little difference.
There are some things I can do faster in PowerShell remotely, and there are others that I am faster RDPing into a server and doing it in the GUI or from PowerShell on the server.... and in cases of my current environment, the SysAdmin machines are not joined to AD (I can understand this to some degree).
The Windows World, for as long as I have been a part of it has always been about the GUI -- especially from Windows 95 and on. If you feel more comfortable RDPing into your servers, a properly secured RD Gateway is just as good as a Linux / SSH Jump box (arguably, you could use a jump box for Remote Desktop as well with software that supports it).
Now as of late, the Windows world has begun a transition to "gui-less" servers, to reduce attack surfaces, and such. I think that's a great Idea, but I also recognize that some Windows SysAdmins will simply never be comfortable in PowerShell, and they will always prefer a gui. As time marches on, I think that number will shrink.
Even in the Mac world, the servers are largely GUI-driven... It just goes back to the base of the OS and what the SysAdmins are comfortable with.
Enter the Penguin: Linux servers, by and large, in my career have all been GUI-less and managed via SSH, which has been great. It's fast, and offers similar protections to disconnects as RDP (tools like screen and tmux come to mind). Linux systems, to me, make sense to manage.
There's not much to say about remote management in the Linux world, because it has been around for so long, and exists just the same in the "servers" vs a system with X installed -- SSH works just fine for Linux, and I doubt that will change any time soon. Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
-
@BRRABill said:
@scottalanmiller said:
Exactly. All of the GUI-less tools were robust by 2003. That the GUI was still provided and the only option was because the 100% GUIless world across the board was not quite ready yet. But pretty much any normal shop had the option. It was extreme edge cases that had to use a GUI, unless you were running Exchange.
I still contend for smaller shops that do very little admin tasks, the GUI is the way to go.
I don't agree but it's for business, not technical reasons. If you had a shop managing a server that only does it once in a while, yes, a GUI makes sense. What doesn't make sense is a shop doing that. Why would you have someone manage a server only once in a while? That means that you either have to have that person maintain a set of skills that are very difficult and expensive but not leverage them while they also have to maintain other skills and use them all of the time. How can they be either good at their job or cost effective? You pay a premium to get a minimum.
This is just not a scenario that should really happen. This is what I often point to as the "one fundamental non-good practice leads to what appears to be good logic for doing others". Because we start from the assumption that we have a strangely inefficient IT structure, we then start doing other weird things based on that assumption. Therein lies the rub.
If, instead, you have an IT design where people were doing dedicated tasks you would not only have lower cost people (because paying one person to master multiple things makes them crazy expensive) but more focused, trained and efficient ones. A full time Windows Admin has massive advantages over a part time one - they don't task switch as much, they get more experience, deeper knowledge and will not just do things faster, they will be more aware of common mistakes, best practices, tools, etc.
That full time person doesn't just make things better on their own, they also start moving you towards better tooling and processes. Instead of saying "it's too costly to learn PowerShell for this one task, I'll never recoup the learning time" they already know it and you get the benefits of that. You get layers of greater efficiency plus deeper knowledge and experience.
-
@dafyre said:
The Windows World, for as long as I have been a part of it has always been about the GUI -- especially from Windows 95 and on.
It is important to remember that the Windows NT world is what we use, not the DOS/Windows world that Windows 95 was a part of. Core administration on the DOS/Windows world always required non-GUI skills, they never really overcame that.
In the NT world, they tried going all GUI and learned very quickly that this made them non-competitive. Things were hard to do, hard to learn, slow to be done, the systems themselves were very slow... they almost immediately began trying to fix this. By Windows 2003 they had essentially made the GUI old hat and had announced that the Windows world was a GUIless one in the future. By 2008, the GUI was a fallback only and not the primary management system by intent (as in, MS' best practices were to go GUIless and use remote tools.)
So the only real window of GUI-centric from Microsoft was 1994 - 2003, nine years, but only nine years and NT was only dominant from 1996 onward, so more like seven years. That seven years, MS took quite a beating and it remains the period that makes people look down on them as not being a serious OS even though since then the product has been awesome.
The idea that Windows is GUI based or GUI-centric comes from the "1998 Problem" that we see so much in IT. So much of what we know was solidified in that year and passed on generation to generation and people stopped questioning it. But like RAID 5 spinners and split arrays for databases and Parallel SCSI and running physical installs... using a GUI for administration finally gave way in the Windows world to bring it in line with the big iron world from the era before.
-
@dafyre said:
Now as of late, the Windows world has begun a transition to "gui-less" servers, to reduce attack surfaces, and such. I think that's a great Idea, but I also recognize that some Windows SysAdmins will simply never be comfortable in PowerShell, and they will always prefer a gui.
This is a huge difference in the Windows and Linux world. In the Windows world, they still call them system admins and act like it is okay. In the Linux world, while GUI and GUIless exist in identical ways, the culture is that if you need a GUI, you aren't ready for entry level systems administration. The communities hold themselves to different standards.
The reasons why no GUI are myriad. But here are some:
- In the non-virtual world (where Windows lived longer than any other OS) the overhead of a GUI is trivial. In the virtual world, it adds up. When Linux can install with 11MB of RAM, the Windows GUI suddenly looks very, very bloated. That GUI can cost rather a bit of money when you start pricing it over time. It adds a small need for additional CPU, a small need for additional storage and rather a large need for additional RAM. Just look at NTG, our average Windows install uses 400% of our average Linux install. 400% is not trivial. And we have some Linux at half that, but no Windows at less (if it has a GUI.) Moving to Windows Server Core or even Windows Server Nano are critical to Windows being performance and resource competitive. Take this to the IaaS world and the cost of the GUI explodes. It can often double costs.
- GUIs mean more code, often more than double the code, and more code means more risk and more patching. GUIs cause patch cycles, patch risks and everything related to increase. You have more to patch and more to go wrong.
- GUIs mean more bandwidth. Trivial for most shops today, but as a remote worker I feel this tremendously even today. Every time I have to use a GUI I feel pain. Pain of waiting, of unresponsiveness. GUIs lower your flexibility and options while increasing the hit on your bandwidth.
- Based on the above there is additional risk, GUIs can update a screen more slowly than they have changed input parameters. GUIs make it easier for a mistake to be made that falls completely on the interface, a new type of risk. It's uncommon but many of us have seen it where we chose one thing and we've actually clicked somewhere else because the GUI was updating beneath the mouse. For an end user, this is trivial. For administration, this is huge.
- GUIs are fragile. Both Windows and Linux, doesn't matter, the GUI fails more often than the rest of the system. It is big, it is complex and it has to do complex things. Everything from desktops to servers the GUIs are more likely to fail and more likely to cause other things to fail.
- Common Denominator of Administration: you don't always know what you will have when you deal with a new machine. This is why on Linux we teach people to use BASH, vi and similar tools because you know that you will have them every time, no matter what system you are on. You will always be able to do your job. For Windows, this means PowerShell. Just because all of the systems you use today have a GUI doesn't mean that they all will tomorrow. Maybe a vendor won't support Windows with a GUI. Maybe you need to do a new job or support a new system or move to IaaS and the cost is too high with a GUI. GUI dependency puts the unknown at risk.
- GUIs are not available on all platforms. Not all editions of Windows support a GUI. If you need a GUI, you lack that ability to use. Limited (today) but an increasingly likely thing. What if Windows Server has no GUI in the future for any version?
- GUIs have a bigger attack surface.
-
@dafyre said:
Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
These work for Windows, too.
-
@scottalanmiller said:
What if Windows Server has no GUI in the future for any version?
I wonder how many software vendors won't make updated software for a GUI-less Windows Server?
-
@scottalanmiller said:
@dafyre said:
Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
These work for Windows, too.
I just found this out. So that helps a lot too.
Like i said -- I'm all for GUI-less servers (regardless of the OS)... but the sys admins for those servers have to be (or get) comfy running the system from RSAT or Powershell.
-
@scottalanmiller said:
I don't agree but it's for business, not technical reasons. If you had a shop managing a server that only does it once in a while, yes, a GUI makes sense. What doesn't make sense is a shop doing that. Why would you have someone manage a server only once in a while?
Even though I am in that scenario, personally, I agree with you 100% here. If I (god forbid) died tomorrow I'm sure they wouldn't replace me with another "IT guy".
-
Do you consider using RSAT going GUI-less?
-
@BRRABill said:
Do you consider using RSAT going GUI-less?
Is there a GUI on the server or not? If not, then it is GUI-less.
How you choose to manage said server is a different question.
-
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
-
@JaredBusch said:
@BRRABill said:
Do you consider using RSAT going GUI-less?
Is there a GUI on the server or not? If not, then it is GUI-less.
How you choose to manage said server is a different question.
Getting me started on "The Bad Old Days" must you? The first UNIX environment I was an admin in was way back right after Y2K. IRIX had an X11 gui server installed by default, weather a monitor was connected or not. The server just had an old terminal connected to a serial port. Didn't slow anyone down in running the different engineering design applications from running them on the server remotely.
-
@BRRABill said:
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
RSAT is a GUI yes. But the Windows Server you are connected to may not have a gui.
-
@FATeknollogee said:
@FATeknollogee said:
@Dashrender said:
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@FATeknollogee said:
Not to side track this thread (apologies to @BRRABill ), what is the "hyperconverged" equivalent in the XenServer world?
To all you XS experts, what is the "hyperconverged" equivalent in the XenServer world?
Similar to Starwind in the Windows world
XenServer is natively that in the Xen world. Nothing additional needed.
If you had 2, 3 or more XS bare metal installs with local drives, how do you "hyperconverge" all the local disks?
Are you saying with XS the "hyperconvergence" just auto-magically happens?
Of course not, but it doesn't for any platform. If you're setting up a greenfield situation, then you design it from the ground up with XS with single shared storage.
Let's try this again:
In Windows, you can take multiple boxes, add Starwind or Datacore = hyperconverged using local storage (no SAN needed).
How do you do the same thing with XS?
This can do HC for XenServer:
http://www.atlantiscomputing.com/products/atlantis-usxIt's interesting how much of Xen did they sell.
-
@BRRABill said:
@JaredBusch said:
Is there a GUI on the server or not? If not, then it is GUI-less.
I ask in relation to his comment:
"the culture is that if you need a GUI, you aren't ready for entry level systems administration"Isn't RSAT a GUI? Regardless of whether your server has a GUI?
It's a GUI on top of a non-GUI interface. It is an API. The server doesn't have a GUI itself, you are talking to a text or binary interface (the Windows API, pretty sure it is binary.)
Just like you could build a GUI for Linux that connects over SSH and uses normal commands under the hood. Yes, YOU might be looking at a GUI, but the servers themselves don't have GUIs.
RSAT as a GUI is different in some important ways:
- It is one to many. One RSAT interface for all of your servers, all of your Windows servers at least. No different than how ELK is a GUI for all of your logs.
- It is light. The server(s) only do a light API, all of the graphical processing is on a client machine where load does not matter, and you don't create overhead or exposure on the servers.
- When not in use, it goes away. It does not use resources when things are not in use. Turn it off, it shuts down.
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
Of course now there are tools like Ansible, Puppet, and Chef that can help with management as well.
These work for Windows, too.
I just found this out. So that helps a lot too.
Like i said -- I'm all for GUI-less servers (regardless of the OS)... but the sys admins for those servers have to be (or get) comfy running the system from RSAT or Powershell.
Indeed, they sure had better. I had someone in a Facebook thread in response to my BASH and SSH on Windows post say that my post was wrong because.... "anyone that doesn't live in PowerShell cannot be considered a Windows Admin and is only a hobbyist." Not the exact quote, but really close. I was told that my article was uninformed and that I didn't know anything about Windows because I accepted people who use anything other than PowerShell as IT pros rather than hobbyists. Me!! @JaredBusch will tell you, no one is more brutal on people using the "wrong" tools or doing things in a non-best practices way or condescending (I like to call it... pushing people to be better) than I am. And yet, even in an article pointing out how important CLI is on Windows, I get flak for giving Windows people way too much credit and that everyone is just a hobbyist.
Which, to be fair, in the Linux world if you said you needed a GUI everyone would laugh at you and no one would let you claim to be a Linux Admin without knowing the command line. If you went into an interview and said you had been one and didn't know the CLI they'd say you lied on you resume and kick you out.
So he was just holding Windows Admins to the same standard. The issue is that it is an absolute standard rather than a relative one. The Windows world has a different culture and using the GUI, for better or for worse, is broadly accepted. It is what it is.
-
@BRRABill said:
Do you consider using RSAT going GUI-less?
From the standpoint of "is the server running a GUI", yes. RSAT is a viable way to admin Windows boxes. Is it a GUI, yes. So from the perspective of "doing administration via scriptable command lines", no.
-
So in reference to what I had posted that prompted this... which was about whether the server should have a GUI, then yes, using RSAT is absolutely GUIless. The server has no GUI.
If I told you that you needed to stop using GUIs and only work from the command line, then no, the RSAT would not meet that requirement. But that was not the context of the discussion. This was purely around how the servers get managed.
Likewise, XO is a GUI for XenServer just as the RSAT is for Windows. But XenServer itself doesn't have a GUI, XenServer has the XAPI API.
-
@KOOLER said:
@FATeknollogee said:
@FATeknollogee said:
@Dashrender said:
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@FATeknollogee said:
Not to side track this thread (apologies to @BRRABill ), what is the "hyperconverged" equivalent in the XenServer world?
To all you XS experts, what is the "hyperconverged" equivalent in the XenServer world?
Similar to Starwind in the Windows world
XenServer is natively that in the Xen world. Nothing additional needed.
If you had 2, 3 or more XS bare metal installs with local drives, how do you "hyperconverge" all the local disks?
Are you saying with XS the "hyperconvergence" just auto-magically happens?
Of course not, but it doesn't for any platform. If you're setting up a greenfield situation, then you design it from the ground up with XS with single shared storage.
Let's try this again:
In Windows, you can take multiple boxes, add Starwind or Datacore = hyperconverged using local storage (no SAN needed).
How do you do the same thing with XS?
This can do HC for XenServer:
http://www.atlantiscomputing.com/products/atlantis-usxIt's interesting how much of Xen did they sell.
You mean how much of their sales is XenServer vs VMware? (since they support both)
-
@BRRABill autoboot issue fixed: https://github.com/vatesfr/xo-web/issues/879
Will be released in 4.16. Thanks for the report!
