Reduced boot time, lower overhead, deployment speed, consistent environments, better resource utilisation, security, flexible isolation, better clustering options, no VMWare licensing fees, image signing workflows & a few more...
- lower overhead, better resource utilisation: agree
- deployment speed: agree
- consistent environments: a standard docker image is not adding anything over a standard VM image.
- security: I am not a specialist but I doubt containers offer the same level of hardware enforced separation that VM offer
- flexible isolation: what do you have in mind?
- better clustering options: but the SQL server software itself is doing the clustering? Otherwise you will end up with inconsistent datasets
But what I don't understand is the concept of a standard container image. That means this only applies to scenario with static data in the database? Unless this is for database sharding, where you fire up a new empty database to extend a database pool?
I would imagine that this would be much more for testing, as it allows for an isolated, empty db for each load. Beyond that, if you're doing a completely containerized infrastructure. Though I would submit that if you're doing windows containers, odds are you're either internally publishing or publishing to azure, so for production, dedicated SQL server or azure sql would likely be better options.
[0] https://msdn.microsoft.com/en-us/virtualization/windowsconta...
Security & Flexible Isolation - I can easily share volumes, link and build overlay networks between containers whilst also keeping everything else namespaced and isolated. containers also isolate processes from each other and allow us to control resources granted to processes (cgroups) which is a security benefit over vm
Clustering - Yes SQL server will cluster, but in a container orchestrator we will get more control of moving processes between nodes to scale, to cover failure scenarios or maximise resource usage of the underlying hosts
Standard Image - You would deploy SQL server container but keep data outside as a volume. Maybe devs would populate the database from a script or network share, or yes join a cluster.
For one they seem to use the single known account (sa) which we disable EVERYWHERE because it's the first biggest known most common target of attack. In fact it's dangerous to use because it will lock randomly when anyone inside the company or elsewhere runs a scan and attempts a few passwords on it.
Secondly SS is made to be patched. We get a new patch every single fucking month and sometimes twice a month. I spend 4 days per month simple patching SQL across half a thousand servers. This shit will never see it. Is this patchable? Not by any standard tools.
Is this even discoverable? Fuck no. Nobody will know it exists. We don't do port scans - we look for known SQL services and use the SMO WMI ManagedComputer tools to identify them. This will work with neither.
I've seen what developers do to their environments. Hundreds of copies of their databases. No backups (so logs grow and fill the disks and then I get called). No maintenance. Of course Express has no job scheduler so you're fucked anyway which is why I don't support it and instead move everyone onto Developer edition WHICH IS FREE.
Anyone using this shit is on their own.