back to article Contain yourself – literally. You can't avoid Docker, K8s for long

Do you remember those guys that invented virtualization, founded a company, got rich and lived happily ever after, remembered fondly by all? Well, that’s almost the story of VMware. But we might see a different story with some of the people behind Docker. For several years, Docker has been a very important technology for my …

  1. Korev Silver badge
    Stop

    Sun Microsystems invented Java, an important technology that became the foundation of a whole industry, but never profited much from it. In the end, Sun lost its independence and was taken over by Oracle.

    Maybe this fate threatens the company behind Docker, Docker Inc.

    Docker didn't invent containers on Linux, they just made them easier to use and also did a good job with the publicity.

    1. stephanh

      "Docker didn't invent containers on Linux, they just made them easier to use and also did a good job with the publicity."

      James Watt didn't invent the steam engine, he just improved upon the machine invented by Newcomen and also did a good job with the publicity.

      The D in R&D is just as important and difficult as the R.

      1. Scott 26
        Childcatcher

        ObBlackAdder quote

        >James Watt didn't invent the steam engine,

        >he just improved upon the machine invented by Newcomen

        >and also did a good job with the publicity.

        Opens newspaper to situation vacant section.

        "I see James Watt has invented a moving kettle and wants help with the marketing"

    2. Anonymous Coward
      Anonymous Coward

      Docker works pretty well as built into Server 2016, but it's not going to replace Hyper-V any time soon.

  2. astrax

    "In addition, Docker solves another problem: installing software. Before Docker, developers had to use tools such as Chef or Puppet to install software reproducibly."

    I would argue that the idea of Docker replacing the requirement for some type of configuration management is just plain wrong. Whilst it is true containerisation provides a very convenient way of deploying discrete applications without the risk of updating relevant libraries or packages, in my experience you still need a method of controlling the actual configuration of those microservices (things like nginx.conf or dhcpd.master for example).

    The real power of containerisation is when you integrate that technology stack into a CI/CD pipeline where your unit testing (or whatever quality control is imposed) is as close to production as it's going to get. Part of that pipeline is usually something like Chef or Puppet which controls the state of those configurations as well as dynamically updating them depending on the environment (templating).

    Other than that, pretty good article :)

    1. Claptrap314 Silver badge

      The CI/CD pipeline is certainly the correct place for a company to learn to use containers. If the team has enough imagination, it will open entirely new options. But in production? Oh, baby. You ain't seen nothing yet.

    2. ewolff

      Thanks for the nice feedback! You are right - I ignored configuration management a little bit as I was talking about just installing the software. However, Kubernetes supports ConfigMaps and tries to tackle that problem now, too. We'll see how that turns out...

  3. Anonymous Coward
    Anonymous Coward

    Rocket/rkt?

    How did you write this article without mentioning Rocket/rkt? My guess is that if Docker goes out of fashion it'll be because Rocket/rkt has replaced it.

    1. ewolff

      Re: Rocket/rkt?

      Thanks for the questions. Quite honestly I don't see a lot of people using rkt so I am pessimistic about it I am afraid.

  4. Nate Amsden Silver badge

    vmware made things easy

    Docker makes other things easy, but not nearly as easy as vmware did. There is a ton of work to do containers the right way.

    In the early days of vmware you just installed vmware on your existing OS (before standalone hypervisor existed), and off you go, quite intuitive. For the most part things worked the same in VMs (from a functional perspective) as outside VMs.

    There is some docker work going on at the org I am at, I haven't done any of it myself, but I have seen from the sides the amount of effort it is taking to tie it together. Not something I have any interest in getting involved with.

    On the flip side I have spent a decent amount of time with LXC(and we have had it deployed to production for the past 3+ years) and it works fine, solves several needs(great for stateless web servers where scalability is not well known) though itself is not perfect. Far easier to get up and going with LXC than with Docker as by default LXC is similar to a Linux install. You have an IP, you have a file system, you can run all the regular linux things inside the container. We manage our LXC containers with Chef(I am no fan of Chef, way too complex, but more effort to change to something else than stick to it - I miss CFEngine v2 which I used prior to Chef) just like the VMs.

    To clarify a bit we run LXC on bare metal hardware, that is one of the benefits for us anyway. Taking out the CPU scheduling component of the hypervisor. Running LXC inside of a VM(for me other than testing purposes) would be a waste.

    Of course we don't use LXC like most people use Docker. My LXC containers have runtimes measured in at least months if not years.

    To me docker solves a problem that shouldn't exist - horribly built applications that break often, agile, low quality, interdependency hell that makes DLL and RPM hell seem like a vacation by comparison(hello ruby and node), and just such crap that the only way they can manage it is by putting it all in one thing. It's really sad. Then there's the "oh just download this script, run it as root and it will setup everything for you" mindset which is just as bad.

    I mean I thought ruby was bad when I first supported an app stack running it 11 years ago. But holy shit it's just gotten FAR worse(and node even worse than that) when it comes to bat shit crazy dependencies.

    (been supporting in house apps/infrastructure at various companies for the past 18 years now)

    1. Claptrap314 Silver badge

      Re: vmware made things easy

      You're making some very good points, but I think it might be worth your while to back up & give this stuff a hard look. At least two of your main points can be addressed by bringing all of your dependencies in house. It will also take care of some more issues.

      Crap software is crap. And I'm sorry if you've been stuck trying to get it up/keep it up. But microservices were invented to address a serious set of problems inherent in monolithic applications. Of course, if management is switching development paradigms to be cool or to cover up for their own incompetence...

      But try running hundreds of applications on tens of thousands of boxen in an environment where the users expect pretty much 100% uptime. You'll go mad or you will end up with something that looks an awful lot like the companies which are doing it--and that is containers.

  5. Brian Miller

    docker build ... Ah, crap!

    Docker is wonderful until you try to build a container, and it doesn't work because of some obscure thing. Right now I'm fighting a Python pip problem. Works great outside of docker, fails miserably inside. "No compiler or bogus args" is what the message is like. No fun.

  6. schuzev

    Swarm and Docker EE

    Docker (the company) eventually realized popularity of k8s and added support to enterprise edition, basically managing swarms and k8s all together. Same as AWS with EKS or MS Azure.

  7. This post has been deleted by a moderator

    1. Claptrap314 Silver badge

      Re: LEARN WHAT IDEMPOTENT MEANS YOU NOOB

      Dude, chill. Idempotentcy is a property, certainly. But the use of idempotent functions to achieve a goal is also certainly a technique. People get sloppy like this with language all of the time, but the intent of the communication is clear.

  8. Anonymous Coward
    Anonymous Coward

    Virtualisation != containers

    The two are typically used to achieve different things and for different reasons. Sometimes not very technical ones - for example to achieve cost-effective licensing of enterprise technology platforms. Yet every Docker article I read seems to compare (and never contrast) them. I haven't used containers but from everything I read I see no reason why the two would not be complimentary but they are not (necessarily) the same and exchangable.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022