November 18, 2014 at 8:32 pm
Comments posted to this topic are about the item The SQL Server Container
November 19, 2014 at 5:43 am
I am really looking forward to this. From a .NET developers point of view this takes the AppDomain abstraction of isolation to a whole new level. I love the idea of more and simpler isolation.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 19, 2014 at 6:14 am
Containers, packages, modern source control, .NET going OSS, CLI administration...
As we say on the Unix/OSS side of the house, you're welcome! 😛
Actually, let's hope there's more cool cross fertilization coming to the Windows world that makes our lives easier.
November 19, 2014 at 6:30 am
Sql Server will need to offer something along the lines of what you have described. There are several structured and non structured *nix based offerings that currently work in containers. The ease of deployment and the cost effective operations are great selling points.
I wonder why there is so little talk of clustering and portability when Docker is discussed by folks from Microsoft world. Imagine configuration locally that runs in other environments by simply moving the files.
November 19, 2014 at 7:42 am
This could be something for us. We do a lot of virtualization.
November 19, 2014 at 3:54 pm
At a very large ISV company that I worked for we had a policy that one thing ran on one machine. One box for SQL Server, one for e-mail, one for the main application, and one as a server for wireless devices.
We found that most of the time if there was a server slow down it was because some operator had walked off and let the console signed on. Not only was this bad for security but the resource consumption of the GUI was enormous.
A Windows server OS that had only text based interface would be great. Administrators would then have to back to thinking for themselves and not having the GUI turn things red that need attention. (I'm kidding. Admins do think.)
For server configuration a CLI should work as well as a GUI. Then all of that stuff that will run every monitor and mouse ever made could be gone.
ATBCharles Kincaid
November 20, 2014 at 2:50 am
Charles Kincaid (11/19/2014)
At a very large ISV company that I worked for we had a policy that one thing ran on one machine. One box for SQL Server, one for e-mail, one for the main application, and one as a server for wireless devices.We found that most of the time if there was a server slow down it was because some operator had walked off and let the console signed on. Not only was this bad for security but the resource consumption of the GUI was enormous.
A Windows server OS that had only text based interface would be great. Administrators would then have to back to thinking for themselves and not having the GUI turn things red that need attention. (I'm kidding. Admins do think.)
For server configuration a CLI should work as well as a GUI. Then all of that stuff that will run every monitor and mouse ever made could be gone.
I would suggest only allowing remote PowerShell sessions as a default position for operational duties. If the GUI is needed it must be justified. Not knowing how to do it in PowerShell is only a reason if it cannot be researched (and then shared).
As a developer who rarely touches production machines (good job too) I never realised or even thought that having a Windows session (I assume that RDP would cause a similar issue) could cause such a perform issue.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 20, 2014 at 10:25 am
Gary Varga (11/20/2014)
I would suggest only allowing remote PowerShell sessions as a default position for operational duties. If the GUI is needed it must be justified. Not knowing how to do it in PowerShell is only a reason if it cannot be researched (and then shared).As a developer who rarely touches production machines (good job too) I never realised or even thought that having a Windows session (I assume that RDP would cause a similar issue) could cause such a perform issue.
This isn't bad, but PoSh isn't a great answer always. It certainly allows you to make mistakes quickly. Or run something on the wrong machine. Used to see that in xWindows, pick the wrong shell window on the wrong machine.
I'd love to see the GUI's there, but without an "Apply" or "execute" button. Just produce a script that someone can see the underlying PoSh and choose to run (or re-use).
November 20, 2014 at 12:34 pm
Steve Jones - SSC Editor (11/20/2014)
Gary Varga (11/20/2014)
I would suggest only allowing remote PowerShell sessions as a default position for operational duties. If the GUI is needed it must be justified. Not knowing how to do it in PowerShell is only a reason if it cannot be researched (and then shared).As a developer who rarely touches production machines (good job too) I never realised or even thought that having a Windows session (I assume that RDP would cause a similar issue) could cause such a perform issue.
This isn't bad, but PoSh isn't a great answer always. It certainly allows you to make mistakes quickly. Or run something on the wrong machine. Used to see that in xWindows, pick the wrong shell window on the wrong machine.
I'd love to see the GUI's there, but without an "Apply" or "execute" button. Just produce a script that someone can see the underlying PoSh and choose to run (or re-use).
Definitely better if an already tested script can be applied but I have known people to perform actions on the wrong server via remote execution of scripts, remote consoles, RDP, GUIs connecting remotely and, strangest of all, stepping up to the wrong physical machine. Always possible to select the wrong machine but I suppose some techniques make it harder
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 20, 2014 at 4:32 pm
Gary Varga (11/20/2014)
As a developer who rarely touches production machines (good job too) I never realised or even thought that having a Windows session (I assume that RDP would cause a similar issue) could cause such a perform issue.
Yes Gary RDP opens a Windows session much like "being there" and signing on at the attached keyboard. I have seen a couple of instances where multiple RDP sessions where several people were looking at the same server congestion problem. I made everybody log off and we moved to a room with a large screen. Not only was it less resource consumptive but we were better off by the "brains in the same room" effect. 🙂
Under the old XP version I was called by the sister of a friend who said that she could not get anything done on her laptop. I found that her wallpaper background picture was 128MB on a 1gig machine. No wonder that it would not even start her spreadsheet application. Switched to a solid colorbackground and problem solved.
Don't take me wrong. I love the cat videos as much as the next person but I still think that servers should be dumb as a post and get the work ov being a server done.
ATBCharles Kincaid
November 21, 2014 at 1:47 am
Charles Kincaid (11/20/2014)
...Don't take me wrong. I love the cat videos as much as the next person but I still think that servers should be dumb as a post and get the work ov being a server done.
Totally agree. There is so much on Windows Server that I don't even want there (no matter how useful on infrequent occassions).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 6, 2017 at 5:42 pm
This is certainly interesting. As a transplant from MySQL and Linux to MS SQL and Windows, I have been surprised that this was something that was missing. I know this is an old post, but a recent article, An Introduction to SQL Server Containers[/url], is rather interesting as it seems to address this topic.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply