Containers Are The Present, Not the Future

  • Comments posted to this topic are about the item Containers Are The Present, Not the Future

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • While I agree with a lot of the content of this article and I can see how containers deliver value, I do worry about implementing platforms that inherently less reliable than the ones they are replacing. In the early 1990's I could deploy databases and achieve 5 9's uptime. Nobody running in the cloud or containers seems to be able to achieve close to that. Not saying data is lost, just the extra layers reduce the reliability.

    Happy to be proved wrong of course.

  • I think that people take a while to grasp the implications of any technology shift.  Fred P Brooks "There ain't no silver bullet" still holds true.

    When VMs came along we thought of them as simply 25% less powerful versions of the equivalent spec physical machine. It took a while to grasp that we could script them, parameterise the script, refine and improve the script, add software + software config to the script.  All of a sudden dev, test, prod etc could be guaranteed to be identical. We could spin up experimental and training environments for a short period of time. We could rehearse service pack,  hot fixes on exactly the same kit as production.  Then we worked out we didn't need to do that! We could build a machine at the latest patch level, install our software and run automated tests.

    Hypervisors improved, tooling and scripting improved. A lot of our concerns were addressed, much of those were addressed by our own education.

    Containers are gripping people's imagination now. Why have an entire VM when you only want to run a few simple functions?

    But containers are not tomorrow's technology. Start reading about unikernels. A unikernel contains only the bits your app needs and that includes only the bit of the OS you app needs. We're back to apps measured in Kb! These things spin up and shut down so fast that they don't exist long enough to hack even if they contained something to hack and for most apps they won't!

  • If you truly need 5 9s of up time, the hardware is still out there and available. I was talking to someone last week who had the need for a warehouse with truly fast performance, so they built it all locally. Saying that we should embrace one technology doesn't mean we should throw away another. I love my cordless drill. I still own a hammer.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • David.Poole wrote:

    These things spin up and shut down so fast that they don’t exist long enough to hack even if they contained something to hack and for most apps they won’t!

    Oh, I'd put money down that someone finds a way to hack this stuff. However, cool tech. I'll take a look at it.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I have been aware of containers for quite a while and started to look into them several times now. The idea is to experiment in a small way, just to learn the concepts, using the only machine I have: my Windows 10 home laptop (which I do NOT want to rebuild / reconfigure every 5 minutes)

    I have tried to find a low-risk, small "hello world" equivalent starting from ground zero, but without success so far. I realise that I will need to install some software but I only want the absolute minimum. All the "look how easy it is" posts assume I'm a server admin, and usually begin by requiring a host of software I may not be able to fully remove, do not understand the purpose of and may never need anyway.

    Any "for dummies" guidance would be very welcome.

    And thanks to David Poole for a great potted history - one of the best I've seen so far.

  • mosaic-287947 wrote:

    I have been aware of containers for quite a while and started to look into them several times now. The idea is to experiment in a small way, just to learn the concepts, using the only machine I have: my Windows 10 home laptop (which I do NOT want to rebuild / reconfigure every 5 minutes) I have tried to find a low-risk, small "hello world" equivalent starting from ground zero, but without success so far. I realise that I will need to install some software but I only want the absolute minimum. All the "look how easy it is" posts assume I'm a server admin, and usually begin by requiring a host of software I may not be able to fully remove, do not understand the purpose of and may never need anyway. Any "for dummies" guidance would be very welcome. And thanks to David Poole for a great potted history - one of the best I've seen so far.

    If you install Docker, minimum, you don't need to be a server admin to figure things out. Microsoft has a great guide on using containers with SQL Server that I've followed successfully to get myself started on learning them.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • This was removed by the editor as SPAM

  • Grant Fritchey wrote:

    If you install Docker, minimum, you don't need to be a server admin to figure things out. Microsoft has a great guide on using containers with SQL Server that I've followed successfully to get myself started on learning them.

    Thanks Grant, much appreciated. I'll give it another go... 🙂

  • It would be very helpful to have a clear definition of what the term "container" means.

    What is the difference between a container and a virtual machine?

    I was persuaded to enter the database field by the simplicity, clarity and universality of the relational model. It would be a tremendous help to me to have such things as the deployment part of Kubernetes in relational terms. Deployment is, after all, a data management issue. The same would be true of Git - the Git data model represented as a relational data model would be an enormous help in understanding. Relational is a much more comprehensive method of data representation than either the hierarchical approach that is apparently used in Kubernetes, or the graph approach used in Git.

    Ideally I would like to have tools based on the relational model, so I am free to query the data in the flexible way we have come accustomed to with relational DBMSs rather than have to rely on commands or APIs.

  • Loosely speaking a VM behaves and has the same demands as a physical machine. It needs an OS and all the baggage that goes with it.

    A container is ringfenced for your application but shares the host OS. That means that a container is smaller and faster to boot up.

     

    I could have a container running PostGres, another running Python 3.7 with a bunch of libraries, Python 3.9 with a different set of libraries and versions of those libraries, a SQL Server container etc. All independent and not interfering with each other.

    If I installed those things on a single machine rather than in containers I might get a conflict between apps or the libraries they use.

    I haven't touched a VM for ages but I do use containers all the time.

    I recommend looking at videos, books and training courses by Nigel Poulton. He explains things really well and with infectious enthusiasm.

    I've shied away from Kubernetes (K8s).  It's a level of complexity I just don't need in my life right now. Again, if the time comes when I need it, Nigel Poulton is your man to explain it

  • I could have a container running PostGres, another running Python 3.7 with a bunch of libraries, Python 3.9 with a different set of libraries and versions of those libraries, a SQL Server container etc. All independent and not interfering with each other.

    If I have 2 containers that use SQL Server 2016 and 2 that contain SQL Server 2019, do I have to install a separate SQL Server for each container, or can I define the relation between container and software version, such that patches to SQL Server 2016 need only be applied to one container?

    Software Version     <- Software Version Container ->  Container

    The relation between Software Version and Container is n-to-n.

     

     

  • If you are using Docker a container is a running instance of an image. 1 image can run many containers.

    I would have a SQL2019 image and a SQL2016 image as a starting point.

     

    You can build images from other images so I'd build my desired patch level SQL2016 image from by 1st SQL2016 image.

    I can then run what containers I want based on whatever image I want.

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply