I think you did not clearly answered to the question: "Should ppl learn/use docker or move forward and use containerd or cri-o?"

I think what's left unanswered for me is, okay so if docker and all of its networking and etc is going away. whats taking over? how is the ipam and host-container nat going to be taken care of?

Nice video: This video just clarified the hoopla and garbage that a lot of people are throwing around. Basically nothing changes for people who are using docker tech correctly, which is proabably 98% of people out there anyways, and the benefit is kubernetes made their product more lightweight and not have to worry about the hell annoying updates of docker that happen all the time, and can break (updates are good, but annoying) Disclaimer: I am not an experienced netop/devops, my main role is developer, but I maintain servers on AWS (8 servers) for my side business, and lead netops/devops (not 100% professional, but probably better than the avg 2 yr experienced fool that has blogs online about bullcrap as I have been working with online tech for 18+ years). As for what others are saying: should I learn docker? I think the easiest answer is this: if you don't know why you are using docker, then maybe you don't use it? If you know why you want to use docker, then use it. Docker is a good choice, all others saying: this is better, that is better - yah probably 1-sided experience. Docker is easy to use, esp for beginners and THIS IS MOST IMPORTANT. If people are saying "10% faster" and stuff like that, this is pure garbage, if you know systems, you aren't concerned about 10% faster for your servers/containers, 10% would be MAYBE important for SQL server, when you are at the cusp of a breaking point of the system, but even then, you gotta change the implementation: split DBs into two servers. So rule: 10% faster means nothing, really, because you just spin up another load balanced server anyways to reduce load - these are just foolish people if they want to really make this into an issue. FASTER BY 10% DOESN'T MATTER REALLY. I will give a case where we want to use docker, and docker is good - docker runs on major OSes, and allows you to build containers (which is basically functions like a VM, without the overhead that most VMs have) - for example, we have a system where we have 4 different servers, we use cloud providers and Centos 7 (screw IBM RH), to develop locally, it's great to use dockers so that we can mimic the interactions of servers right on our computer (local dev env). DOCKER IS GOOD FOR DEVS! So on production, when to use containers? You have a choice now (AWS) - use EC2 instances OR use containers. What are the differences, and benefits for each? A lot goes to having experience - if you running lightweight processes that don't do much, like the majority of nodeJs servers people write, and services which they offer, then containers are a great option on cloud providers especially, because it's cheaper to have 1-2 live and 1 backup containers, then lets say than paying for 3 servers. It's almost always safer to have several servers running than 1 super server (what happens if that hardware dies on the super server, your services are GONE). Keyword: load balancing. Now 1 type of server is our web servers, so obviously you want to load balance two or more in production. CONTAINERS COULD BE CHEAPER THAN SERVERS. Is it easier to maintain containers than lets say traditional servers? I'm going to say if you are spinning up 64 load balanced servers, it's gonna get costly, and containers makes more sense, as they were built for huge numbers. But in all small to medium network sizes of small to medium companies, or start ups, it doesn't really matter tbh. If you actually have 1K concurrent users, then containers are great! If you running even apache php servers, you could go with containers too! it's understanding the resources/performance and costs. CONTAINERS ARE GOOD IF YOU WANT TO LOAD BALANCE 100 "SERVERS" ON LOAD BALANCER. In the end, when using cloud providers, like AWS, you have a choice of deployment now - ec2 load balanced or fargate containers. As far as I am concerned, if you don't have 1k+ concurrent users, you might not necessarily use fargate (or kubernetes) and container images. But you never had to because you could always use the traditional methods of using servers. DEPENDING ON REALISTIC SCALES AND WHAT YOUR SYSTEM IS, CONTAINERS OR NON-CONTAINERS ARE VIABLE IN A LOT OF GENERAL CASES. Anyone pushing anything real hard outside of this are just "experts" in their own fields, because all container tech are about the same, docker is great for the dev process, and it's big, like in this video. But those tools AREN'T NEEDED on your production servers (docker full features) because you shouldn't be building debugging your containers on production and for sure, you shouldn't be using docker network layer AT ALL on production. DOCKER RUNNING IN PRODUCTION IS DANGEROUS (SECURITY), DON'T NEED FULL DOCKER ON PRODUCTION ANYWAYS. In the end, you just have to think of a container as a VM and you can 32/64 "servers" in containers on a computer, think of it that way. It's probably safer and better than running 1 service on a computer (in general), which may crash in an edge case or some other weird issue (which maybe due to degradation over time, bad 3rd party software).

]]i

Nana, great video. Isn't the question a bit misleading? Is it not the case that K8s are dropping support for docker shim rather than docker? The K8s support for OCI has never been in doubt and the docker obviously is compliant with OCI. K8s are not required to support individual containers but rather focus on the Open Container Initiative, which is still the case. Would you agree to that?

Yep :D

Glad it was helpful for you 😊

I couldn't agree more. It's been a while since I watched a video about tech, with such a clear explanation of the topic - thx!

😀 thank you so much! I read a lot of your comments and questions and try to answer them in the videos 😊

Thank you Pedro! 😀

Glad to hear :)

Welcome to the channel 😊 Thank you so much for your positive comment!

Thanks Sam, glad it was useful for you :)

Wow appreciate your comment, really happy to hear that my videos are so helpful for you and the whole team 🙂

Thank you so much! Appreciate your comment 🙂 danke :)

Thank you Ilyas, really glad you like my way of explaining it :)

That's awesome, thank you Andrea :)

😊🙏

So did the title of this video!

Hope it was helpful Rohit :)

Thanks so much! :)

Thank you Daniel! Appreciate your comment!

Glad to hear! :)

Thank you so much Henrik 😊

Thanks for your feedback Allen, glad it's helpful :)

Thank you Josh, appreciate your comment :)

She awesome!!!

Happy to hear, thank you 🙂

Thanks a ton Sergio! 😊

Thank you John, appreciate your feedback :)

Thank you for this feedback, appreciate it very much :)

You're welcome Wilfried, glad you liked it :)

That's amazing to hear! Thank you!

Thank you Diego. I'm happy to hear 😊

glad to hear! 🙂

Thank you Pravin 🙂