It's Monday right now 🚀 What are your plans for scaling up your DevOps career in the next couple of days? If you don't have any plans yet, come up with one. 💡 💬 Comment below! (My answer will be in the comments.)

UV is replaced PIP, I am using uv package manager and it's incredibly fast https://medium.com/@sumakbn/uv-vs-pip-revolutionizing-python-package-management-576915e90f7e

I spent a year learning Go, but I switched back to Python. Why? It made it easier to get a job. In my early DevOps years, I used Python every day. But I wanted to learn Go because so much modern DevOps runs on it. WHAT I FOUND LEARNING GO Kubernetes and many cloud tools are built in Go. Most projects are huge and hard to fully understand if you don't write code full time. Now I use AI to help me read Go when I need it. Learning Go was still worth it: - Strict typing - Memory control - Fast single binaries Why I came back to Python: - More jobs here in the Netherlands need Python - Easy to learn but has depth - Huge community and libraries - AI and ML run on Python with PyTorch and NumPy In daily DevOps I write scripts, APIs and small tools. Python does all of this well. It keeps me flexible and ready for the AI side too. WHY BOTH LANGUAGES MATTER Both languages matter: - Go runs so much infrastructure - Python keeps me productive and open to more work Here's what I actually build with Python in my daily DevOps work: - Automation scripts - APIs for internal tools - Small utilities and tools - AI/ML integrations when needed WHAT I LEARNED FROM THIS EXPERIENCE Both languages matter, but in different ways: - Go runs so much infrastructure we depend on - Python keeps me productive and employable I still use my Go knowledge when I need to understand Kubernetes source code or debug cloud-native tools. But for building solutions day-to-day? Python wins. Ready to level up your Python & DevOps skills? Join the KubeCraft community where we share practical projects and land people jobs every week → [JOIN HERE] ​ Cheers, Mischa

Hello friends, We spend so much time writing code and taking notes. What is your favorite editor? After you replied, go through the comments and like similar editors. You can ask for cool plugins or configuration tips too!

Apple quietly dropped something this week that could shake up how we run containers on macOS. They’ve released an open-source project called Containerization, along with a CLI tool called container. It’s aimed at running Linux containers natively on Apple Silicon, but the way they approached this is completely different from what most of us are used to with Docker or Podman. The typical setup today is spinning up one large VM that runs all your containers inside of it. That works, but it’s heavy, introduces overhead, and creates weird limitations around things like port mappings or system resource sharing. Apple’s approach? They run each container inside its own lightweight VM, fully isolated, with its own dedicated IP. No bloated shared VM, no port conflicts, no strange Docker Desktop workarounds. And because they’re using Apple’s Virtualization framework under the hood, startup times are fast. They’re claiming sub-second container startup, and containers only consume CPU and memory while they’re actually running. A few things that stand out: - Full OCI compatibility, so your existing Docker images will run - No core utilities or dynamic libraries baked into the container VM, reducing attack surface - Native support for networking, filesystem sharing, and container management through their Swift-based APIs - Runs natively on Apple Silicon, optimized for performance It’s early. Version 0.1.0, and realistically you need macOS 26 to get the full networking and isolation benefits. But you can see where this is heading. For anyone doing local container testing, running dev environments, or building Kubernetes workloads on Mac hardware, this could be a big deal down the road. Curious how you see this playing out once it matures. Is this something you’d use over Docker Desktop or Podman? Github: https://github.com/apple/container Video: see below.