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

Bass Bass Knows the way the wind is flowing.
  • Bloat,​versioning and Containers

    Docker containers are union mounted (copy on write) by default.

  • Window container support on client

    , evildictait​or wrote

    *snip*

    Google use container abstractions for all of their deployments to datacenter infrastructure.

    For some deployments to Linux, this uses Linux containers under the hood. For most deployments to Linux, this actually involves reinstancing the whole CPU via a PXE boot and installing it fresh on the bare metal.

    For deployments to hardware, this is done via a network signed boot and FPGA flush.

    For deployments to Windows servers, this is done mainly via virtual machines which revert to a "known good snapshot" and then running what amounts to an installer to install, self-test and deploy.

    It's confusing because "container" is the name of the abstraction and the Windows and Linux implementations and the name used by third parties that leverage those APIs (like Docker).

    Where are you sourcing this information from?

  • Window container support on client

    , kettch wrote

    *snip*

    FYI, there is no such thing as proprietary .NET. It's all fully open source. .NET Core and CoreCLR are simply the cloud optimized binaries that are currently supported on non-Windows OS'.

    So that's the point. It's open source. I can run it on Linux. I don't need Windows anymore for .NET. That's great for .NET developers and adoption for .NET. But it's not good for Windows Server [Web Edition, at least]. I was mentioning that Microsoft sacrificed Windows Server to promote .NET. It's possible that they don't really make much money from it (keep in mind, the Web Edition is really cheap), and promoting .NET can have beneficial effects for their other products. But I'm not entirely sure. More analysis here:

    http://channel9.msdn.com/Forums/Coffeehouse/Window-container-support-on-client/6232181d0751403882f3a4920004ab70

    http://channel9.msdn.com/Forums/Coffeehouse/Window-container-support-on-client/398a9c2edff442f38b50a49200073937

  • Window container support on client

    , cbae wrote

    *snip*

    But that is the beauty of Windows on Docker. There IS interoperability. If your devops team has a certain workflow for doing deployments using Docker, the few Windows-based applications that you need to deploy don't become red-headed stepchildren. They're done exactly the same way by whatever orchestration tooling Docker uses for Linux-based containers.



    Which is a very intelligent strategy, and how Nadella-era Microsoft differs from Ballmer-era Microsoft. It's the right direction, but still incomplete. Docker is only one element of the puzzle. There is still no room for Windows in a CoreOS/Kubernetes world.

  • IBM, Red Hat, Microsoft (!!!) join Google's Kubernetes project

    , magicalclick wrote

    Last year???? Is it just the container thing or different?

    Yup. It was a hint that at least some of this stuff will end up in Windows sooner then later.

  • Window container support on client

    And yes there are consequences for doing so. Windows infrastructure is not available in many cloud providers, and the ones that do offer it charge ~30% or more for no difference in hardware. Even Microsoft does this, it's less money to run Linux in Azure. Your private cloud options are also limited. How do you sell a Windows-only system to a customer as a necessary thing?

  • Window container support on client

    , cbae wrote

    *snip*

    Sure, if a developer's role includes doing testing of applications inside a container or doing devops work, then knowing how to create a Dockerfile is probably important.

    But what does this have to do with your original "honest" question?

     

    You didn't really give a satisfying answer IMO. You said some stuff yadda yadda is not in open source .NET. But what stuff in proprietary .NET are so important as to require you to lock yourself totally into a Windows-only infrastructure?

  • Window container support on client

    , PerfectPhase wrote

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

    What are some examples?

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

    Your customers care about what technology you use? What about the actual problem you are trying to solve?

  • Window container support on client

    , cbae wrote

    *snip*

    Sure, if a developer's role includes doing testing of applications inside a container or doing devops work, then knowing how to create a Dockerfile is probably important.

    But what does this have to do with your original "honest" question?

     

    What? What developers fart out things without testing them? Of course that's the role of the developer. The developer also defines how their application should run. That's part of DevOps. That's why it's called DevOps. The modern cloud environment is very developer-driven. The infrastructure is self-healing and managing, if your server crashes your stuff just moves to another server automatically. If your stuff eats up all the CPU, it gets sharded across more servers. And so on. This is not new stuff in Linuxland. None of this is magical though, but it's usually the role of the developer to orchestrate, since developers know the characteristics of their software the best.

  • Window container support on client

    , cbae wrote

    *snip*

    Why does a developer need to have knowledge of Docker containerization? Containers are an abstraction layer that the application need not even contemplate. Isn't that the whole point of containers?

    If you weren't talking about yourself, a hypothetical .NET developer would have to use Windows container if the .NET framework that he targets runs only on Windows. Not all of the .NET frameworks have been refactored to run on .NET core yet, and for some frameworks that may never happen.



    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.

    Anyway my view is, the point of making the container is once you have the build toolchain set up you can deploy your containers to any cloud provider, to Kubernetes, Mesos, CoreOS/fleetd, or OpenStack. Or your laptop. Not that containers are inherently easy/easier to produce then a standard executable. They are not.