Should You Use Kubernetes and Docker In Your Next Project?

    By
    Coding Tech
    -
    16
    24



    In the last few years, the industry has experienced a shift towards
    developing smaller and more focused applications. Smaller services are excellent from a product and development perspective: they are quicker to deploy, easier to iterate on and can handle failure gracefully. But how does that cultural shift impact the infrastructure?

    In this talk, you will learn whatā€™s all the hype about containers and Kubernetes and how they impact the development of your microservices. Daniele is an instructor at Learnk8s, where he teaches Kubernetes and containers to small and large enterprises.

    EVENT:

    Junior Developers Singapore 2019

    SPEAKER:

    Daniele Polencic

    PUBLICATION PERMISSIONS:

    Original video was published with the Creative Commons Attribution license (reuse allowed)

    ATTRIBUTION CREDITS:

    Original video source: https://www.youtube.com/watch?v=7XvgqDlp8sQ

    source

    Previous article2. Jenkins pipeline – Clone Git repo onto Jenkins using Declarative Pipelines
    Next article(#12) Azure DevOps Board with Agile work process | Azure DevOps Boards | Azure DevOps tutorial
    Coding Tech

    RELATED ARTICLESMORE FROM AUTHOR

    24 COMMENTS

    10. "Should You Use Kubernetes and Docker In Your Next Project" The correct question is: "Can your next project run on Kubernetes".
      I believe that Kubernetes should be the basis and if your software cannot run on it, or was not made for it, you should not be using that software and turn to something that does run on Kubernetes.

      It's like the Virtual Machine days, it becomes the infrastructure of choice, and if your software cannot run on the chosen next-gen infra it was to be scrapped and recoded. Well now the next-gen infrastructure is Kubernetes.

    15. This is a critical comment. I am using Docker, and I am using Docker for its most important property. I've come to this "junior level" video to understand Kubernetes from the first principles, as I am still below that level. Unfortunately, I cannot comment on the Kubernentes part of the presentation, but the Docker intro was off its important mark. Also, I must respectfully disagree with my fellow guild member Daniele on lesser points. "VM preallocates resources:" nope, we have ballooning and KSM for that; and a Docker app comes with a whole userland baggage of the OS (libc.so.6 and libX.so.42 etc. etc.) that the main app depends on (and, ladies and gents, welcome KSM back into the spotlight, as KSM is the piece of machinery that accommodates it and makes Docker possible). Nowadays both virtualisation and containment are very comparable, both in their efficiency and resource use. "We like splitting programs into parts:" nope, I like Ancient Greek sculpture and chocolate biscuits, and you like hip-hop and vanilla ice cream, but engineering is not about like or dislike; it is the optimisaton problem in search of the best compromise, for some definition of "the best" right from the inception of a project (it changes as the project goes on, but slowly and reluctantly, and woe to him who has forgone writing the goal down at page one of his notebook). We "like" splitting programs to separate concerns and we "hate" splitting programs because every new boundary is an interaction point. Engineering is the art of choosing your poison. The part about isolation is correct, but it's not exclusive to Docker also: see, for a brief summary, man systemd.exec(5). What had not been not sounded in the Docker part was its main advantage: the reproducible environment. So, when Daniele came to the Kubernetes part, I had to hit stop: I am a complete Kubernets newbie, unable to discern if what I hear is the core reason, be it single or one of many nuclear reasons why it exists and what problems does it solve–or the talk is only skimming the minor and less significant points, as it so unfortunately happened with Docker. Caveat auditor.