GoogleContainerTools' distroless base images are often mentioned as one of the ways to produce small(er), fast(er), and secure(r) containers. But what are these distroless images, really? Why are they needed? What's the difference between a container built from a distroless base and a container built from scratch? Let's take a deeper look.
Many of us these days seem to be in pursuit of better container images. And this is for good reasons! Bloated images with many (potentially unneeded) moving parts slow down development and give more space for a CVE to sneak in. Luckily, there is a number of ways to produce slim and secure images, and everyone just needs to pick
their poison a suitable one. But before doing so, it's good to become aware of a potential dissonance between what we say is important for us (securing our software supply chains) and what may actually drive our decisions (keeping out dev loops fast).
"How to start programming in Go and for Kubernetes?" - the question I often get from fellow DevOps people. This is a tricky one. And I don't have a universal answer to it. However, I do have some thoughts to share.
But first, let me tell you my own story.
In my case, it was rather an evolutionary step - I'd been developing software for almost 10 years by the time I started coding for Kubernetes. I'd also been (sporadically) using Go for some of my server-side projects since probably 2015. And around 2019, I started my transition to, first, SRE and, then, Platform Engineering. So, when I decided to get my hands dirty with Kubernetes controllers, it was just a matter of joining the right team and picking up the Kubernetes domain. Luckily, I had a good candidate on my radar, and that required just an internal transition from one team to another.
However, based on my observations, for many contemporary DevOps engineers, the direction of the desired transformation is often inverse. From Ops to Dev (preferably, for Ops).
Since your background and experience may vary, instead of giving a concrete piece of advice here, I'll try to explain how I'd approach the problem given different levels of proficiency with the technologies.
There are many resources for people who want to learn Linux, Containers, or Kubernetes. However, most of these resources don't come with an interactive, hands-on learning experience. You can read tens of fine blog articles and watch hundreds of engaging YouTube videos, maybe even take some courses with theoretical quizzes at the end, but it's doubtful you'll master any of the above technologies without actively practicing them.
Theoretical-only knowledge of, say, Kubernetes doesn't really count. Hands-on exercises should be a must-have learning element. Some resources, including this blog, strive to provide reproducible instructions so that students can try out the new skills. However, for that, a running system is needed. Setting up such a system can make the learning curve substantially steeper or even make the task fully unbearable for inexperienced students.
So, where can a student practice the new skills?
One option is to experiment on a real staging (or production 🙈) environment. But it can be quite harmful. Luckily, there is an alternative. Some learning platforms offer interactive playgrounds mimicking real-world setups. On these platforms, students can SSH into disposable Linux servers, or even access multi-server stages right from their browsers!
Experimenting with the new skills in such sandboxes makes the learning hands-on. At the same time, these platforms free students from the need for provisioning playgrounds. It brings students closer to real-world environments while keeping the learning process safe - playgrounds can always be destroyed and recreated without damaging any real production systems.
Cloud-Native Learn-by-Doing platforms— Ivan Velichko (@iximiuz) September 25, 2021
A list of sites with interactive playgrounds on
learning .oreilly .com
I got so fascinated by the idea of interactive playgrounds recently that I spent a week researching platforms that provide in-browser learn-by-doing experience. Below are my findings, alphabetically ordered:
I compiled this thread on Twitter, and all of a sudden, it got quite some attention. So here, I'll try to elaborate on the topic a bit more. Maybe it would be helpful for someone trying to make a career decision or just improve general understanding of the most hyped titles in the industry.
DevOps, SRE, and Platform Engineering (thread)— Ivan Velichko (@iximiuz) July 31, 2021
Sharing my understanding of things after working in this domain for about two years.
Starting from the clearest one.
Dev - this is about application development, aka business logic. The only one that makes money for a company.