Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

PerfectPhase PerfectPhase "This is not war, this is pest control!" - Dalek to Cyberman
  • Window container support on client

    , evildictait​or wrote

    *snip*

    No again. Containers are a deployment abstraction, not a performance feature. Containers are not in the same abstraction category....

    *snip*

    You can very easily get into splitting hairs on this.  Fanbaby said containers run more efficiently, but did not qualify that.

    A single container running on a single VM host OS, will probably, by unmeasurably small factor, run slower than if the app was deployed directly on host OS

    Hypervisior->Host OS->Container vs Hypervisior->Host OS->app

    But running multiple containers on a single host OS makes far more efficient use of overall system resources

    Hypervisior->Host OS->Container,Container,Container,Container

    vs

    Hypervisior->(Host OS->app),(Host OS->app),(Host OS->app),(Host OS->app)

    YMMV, its just good to be aware of what the options are, even if you don't use them now.

     

     

  • Window container support on client

    , Bass wrote

    *snip*

    All containers are dervied from images, and images are built using a Dockerfile. Even if your IDE will magically automate building things for you, it's worth learning how things actually work, so I suspect prudent .NET developers will actually do things like read the Docker documentation or other research if they intend to use containers. A developer that relies too much on magical thinking is going to have a bad time if things ever go wrong.

    Compared to understanding the problem domain of my application, working out how Docker/containers work is quite trivial; be that windows or Linux.

  • Window container support on client

    , Bass wrote

    *snip*

    Honest question: Why would I run a .NET application on Windows?

    Can't answer for you, but for me...

    Because I use more of .NET than is included in the CoreCLR and CoreFX, which are still quite anaemic at this time.

    Because that is what my customers use and are asking for.

  • Window container support on client

    @Bass: There was an interview with Scott Hansellman recently, and basically he said going forward MS really wants to sell you compute, be that windows or Linux (they'd prefer you to run windows :P ), as long as you run it on Azure :D

  • Window container support on client

    I note that Beta-5 removes the dependency on mono

    https://github.com/aspnet/aspnet-docker/blob/master/coreclr-1.0.0-beta5-11624/Dockerfile

     

  • Window container support on client

    @Bass: Not surprising as no one outside MS has Windows container support at the moment :)

  • Window container support on client

    @cbae: agreed, I would have thought as a general rule you'll run a single hypervisor type, be that Hyper-V, VMware, Xen, whatever, which will host VMs running Server Core for Windows containers or CoreOS for Linux, for example.

  • Window container support on client

    , cbae wrote

    *snip*

    What does "written against" mean? Inventing terms again?

    If you want to be understood, you should be more careful in your choice of words.

     

    Win32 is an API, you write in a programming language and program against an API, simples.

  • Window container support on client

    , cbae wrote

    But having Windows containers run on a Linux VM means that you won't have to spin up another Windows VM and pay the compute hours just to host a small subset of your application infrastructure that depends on Windows. Likewise, if you're primarily a Windows shop, being able to run Linux containers from a Windows VM means you won't have to spin up an entire Linux VM because you want run some NoSQL database runs only on Linux.

    It's really not that difficult to understand the motivations.

    No that's wrong

    Hypervisor (optional) -> Container Host -> Container

    The hypervisor can be Windows or Linux, but the Container Host OS has to match the container type, Windows Containers on Windows, Linux on Linux.

    If you have a dontnet application running on coreCLR and you want to deploy this to a Linux container host then that's a Linux container not a windows container, so there is no windows OS licence involved.

    If Microsoft decide to license the number of containers running on a host, like they've done for windows VMs on a Hyper-V node, they might as well just throw in the towel and go home now.

     

     

  • Window container support on client

    , fanbaby wrote

    In any case, it makes little sense to deploy windows container to a Windows VM running under Linux vs deploying to a windows server directly.

    'In the real world' you'd be using something like a Mesosphere cluster to scale out and deploy the containers, which would send each kind to their native host types anyway.

    The whole windows on Linux, Linux on windows is only really interesting from a dev point of view anyway.