kuberdenis

Posted on Feb 10

onDocker[v0.1]: Personal Reflections

#docker #writing #containers #productivity

As with any big company / technology, there are mixed opinions about Docker on the internet. It is only natural for a product to be good in something and bad in something else. And it is natural for a product to have competitors doing something better.

In this short post I would like to go over my views about Docker as both a technology and a company. I will try to return my personal tape back to a point where I first got introduced to containers and give my best to put my thoughts into words.

I think Docker is a good company and I think Docker can be a very good product.

From an engineering perspective, I think when one gains enough relevant engineering experience, there are better solutions out there - for both container runtime and local development.

And for the juniors out there, I consider Docker to be the best introduction to the world of containers.

Series Preword

Ok, so I got accepted as a Docker captain and it's been quite some time since I was supposed to make my first contribution so here we are.

I want to turn this onDocker thing into series and push out one article per month.

I don't have any plans yet as to what exactly I am going to create content on but one thing I am certain of - I need to deliver. So if you (reader) ever think of something docker-related, please let me know and I'll probably include it in an episode of onDocker

Computers, Virtual Machines, and Containers

When I was a teenager all my experience with virtualization was what you would typically expect from a teenager - VirtualBoxing Kali Linux, then VMWare-Workspacing Kali Linux, then USB-ing Kali Linux. Nothing Less, nothing more.

At the time I did not really care about any of this, I was just happy I did something techy.

Then I became a SysAdmin and stuff changed... they changed.

Junior to Mid: I am scared of containers

In my first job I was lucky enough to not be in a tech support role but directly jump in on actual system administration. The technologies I used varied a lot - different Linux distros, shady bash scripts, varnish, load balancing, redis sentinels, backup tools, and so on.

The company I worked at had their entire customer setup in VMWare vSphere and I was basically introduced to cloud computing the oldschool way now look at as "self-hosting customer applications".

Until one time I entered a server but there was no webserver installed on it. No Apache, no Nginx. There was no database either. Not even /var/www. "Wait, what?!", I thought. And then a colleague told me to run docker ps -a.

And this is when I got introduced to containers, one year into my tech career.

Docker Community & Developer Enablement

So naturally I used my free time to learn more about Docker at home. Yes, not about containers, but about Docker.

Since I already had some basic experience in web development, I first containerized a plain HTML website (lol).

I had a DigitalOcean droplet for remote development so no Docker Desktop yet.

Then I tried solving a more complex case, like trying to load-balance an OpenVPN connection inside Docker. My colleague decided to play a trick on me and gave me this task. Naively I jumped in and spent three days trying to figure it out but ultimately failed to create a real load balancing solution. I ended up with a half-baked emulation of availability consisting of one HAProxy container, and two OpenVPN-server containers. It looked like I was doing load balancing but there was no session persistence, no state, nothing.

And here I have my first two positives about Docker:

Strong Community: I was able to get so far at the time in most parts because of the great community I found online and countless tutorials present.
New Development Abilities: I was able to use my own machine as a VPC (virtual private cloud) - I did not need multiple VMs, I could craft whatever architecture I wanted on one single VM.

Diving Deeper

Docker then largely contributed to my success in getting my second job as a Jr. DevOps engineer only one year after starting my career. At the time (2019-2020), I believe containers as a technology was not so widely used, or at least not here in Bulgaria.

Anyway, so I got my second job and had to dive deeper.

I got to use different areas of Docker:

Docker Desktop
Docker CLI
Dockerfiles... a lot of Dockerfiles
Multi-Stage Dockerfiles

And now that I reflect back on this, I again give my props to the company Docker for doing what they did to flood the internet with knowledge about containers (doesn't mater if from a marketing perspective, or for the love of the community) and making the technology easy-to-use from a consumer / developer perspective.

I didn't even know but the Docker CLI was actually the first "abstraction" over the harder-to-grasp linux-containers' lxc. I never personally worked with lxc but doing a little investigation writing this article, it does not look like a pleasant experience.

And while some would argue abstractions are bad, I find them to be a good thing. They serve as auxiliary wheels, making what seem impossible, actually possible. Once one has to focus on the core, which would usually take years, then it is my opinion that it becomes important to context-switch, let the abstractions fade away, and do your own time in the trenches, crafting "your own abstractions". But this is a long topic. And it would require me to do a lot more deep thinking before reaching any definitive opinions.

Mid to Senior: I love containers

Right. So in my 2nd - 3rd year in tech, I became more and more capable, started attending Hackathons, and started working with Kubernetes.

Me and a very good friend of mine / hi, Bobby! / once attended a pretty huge prize-pool hackathon and actually managed to win 1st place by utilizing Docker Compose, Docker Volumes, and Docker Network. So again - doubling down on developer enablement. We crafted a Minecraft load-balancing solution on the Hackathon hosts' networking product.

I also started using Compose more for local development at work when I did not have access to my customers' environments. Something that I would otherwise not thing of - to recreate the whole architecture locally so I can work on a feature / fix.

I remember shortly before I would get hired as a senior, I read somewhere that Docker is "no longer free". What does that mean, I thought. I did not put much attention into this, but I remember this was one of the first times I thought, "Docker might not be as good as I thought". But now I completely justify their decision. I mean why would they not start taxing their enterprise customers? I would too. Hashicorp did too. As good as it sounds to live in a world where the only "currency" exchanged is the work we do together, our real world simply does not work that way. And when it comes to corporate-to-corporate, I would believe the only natural progression would be to start taxing your customers. After all, your customers are completely free to decide if they want to pick you over your competitors. And this applies to Docker too.

More on this later but I look at Docker as I do on Ubuntu - Ubuntu is far from a perfect distribution but it is the one with the most tutorials online, it has the easiest hop-on onboarding experience, and it simply works even if it isn't the best in terms of performance and being overloaded with packages.

What I am trying to say is developer experience & community is important. Especially for people not too keen on configuring something from scratch (as with colima for e.g.).

Oh, and one more Junior - Mid-Level positive:

Docker Hub: pretty cool and definitely goes right into my "developer enablement" section

Senior to Beyond: Doubt Taking Shape

So. Here I am writing this post, employed as a senior for 2 years already. What do I think about Docker now that I have spent so much time in tech? Well, that would depend on the quality or rather the activities I spent time on.

Even in my senior years, I still notice the developer enablement is still there for me. Crafting Azure DevOps pipelines, there is the Docker@2 task making it easy to build & push containers. For development and test environments that does not have public internet access, Docker is still my go-to choice.

The day I started doubting Docker came when I saw that my disk space severely degraded and I had a hard time understanding what is causing this case. It turned out that I had orphaned images, like.. ghost images and logs that took ~50GiB. I am not a Docker developer of course but I think a "system check" would not be too hard to implement.

Another "panic moment" I remember was when Kubernetes ended support for Docker as a runtime. We did not get affected by it, except for the fact we had to plan carefully how we update our clusters. Anyway, k8s' post then really opened up a lot of doors for me in terms of knowledge expansion. I got to dive deeper into how Docker worked, gained more knowledge about Kubernetes and I was finally able to make the difference between a runtime and a container engine lol.

Recently I once again received a slap in the face when my Docker engine stopped working on my Mac. I was essentially forced to install Podman (and later colima) which was not exactly expected or wanted. And I just got into Docker plugins!!

Another thing I now don't feel so happily about is Docker Hub. I think it is too pricey and I like my container registry where my cloud is - on DO, AWS, or Azure. I also don't think it would make sense for enterprise because, again, it's far more convenient keeping the CR near the infra.

Conclusion

Yeah, so after all I think Docker is superior when it comes to containers devex. And I think the team understands that, hence the plugins, articles, programs, etc.

For production, I don't think there is any discussion to be had unless it shifts into a discussion of containers vs [ something ] since containers, wether built with Docker, Podman, colima or whatever are treated the same way inside a container orchestrator. It would be a discussion of packaging software.

And one more thing. Writing this article made me realize companies actually posses enormous power over how the industry is being shaped. I think what Docker is doing is good and I think they play their part in the evolution of development quite well. Deep-knowers will go on and fix micro-areas of Docker that the company wouldn't prioritize to fix and this is a good thing. This is how progress is generated - through disagreement and agency. Through competitiveness.

So as everything - apply layers to your thinking, be able to context-switch, and don't draw your opinions from a single source of truth, for there is no such thing.

And that's it. That's the first article in the onDocker series. Again, since I don't have any strict plan on what I am going to write about, let me know if you have any preferences.

Thank you for reading, friend.

p.s. this article is a direct 1 : 1 of my thoughts : words. i did not apply any post-processing whatsoever so it might feel off. no idea. just oneshotted it. lmk how it felt. peace