Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about the new Google Kubernetes Engine Autopilot and how to integrate Kubernetes and Terraform.

1. This was without any doubt the most important Kubernetes news from last week: the release of Google Kubernetes Engine Autopilot mode. A new setting for GKE allowing teams to outsource the operations of their clusters directly to Google, applying the best practices in scalability, security, and performance. Even better, GitLab supports Autopilot right now!

https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot

2. HashiCorp announced last week the availability of the HashiCorp Terraform Cloud Operator for Kubernetes, allowing teams to integrate both systems through GitOps workflows, in either public, private, or hybrid cloud infrastructures. This operator also supports Terraform Enterprise, and as expected, can be integrated on any Kubernetes cluster via Helm.

https://www.hashicorp.com/blog/announcing-general-availability-hashicorp-terraform-cloud-operator-for-kubernetes

3. Speaking about controllers, do you know how they work internally? Do they poll pods continuously for updates, or are they subscribed to receive events from worker nodes? Tim Hockin, principal engineer in the Kubernetes project, explains it all in this presentation.

https://speakerdeck.com/thockin/kubernetes-controllers-are-they-loops-or-events

4. And for those interested in the lower-level details of how controllers work, here is more information about how they work with controller-runtime and client-go.

https://danielmangum.com/posts/controller-runtime-client-go-rate-limiting/

5. The tool of the week is Etok, which as the name implies, allows you to Execute Terraform On Kubernetes. Must have!

https://github.com/leg100/etok

Have you used Terraform and Kubernetes together? Have you written your own Kubernetes controllers? Would you like to share some tips and tricks with the community? Get in touch with us, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about Kubernetes and Terraform: #4, #8, #11, #14, #16, #19, #23, #37, #46, #49, #59, #64, #65, and #74.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about the latest techniques to build the containers that will host your applications in production.

1. Standard stock pictures of containers and cranes in a harbor are a bit cliché, agreed. But this article provides a short and sweet collection of best practices for writing and optimizing Dockerfiles by Kasun Rajapakse. No matter if you use Podman or Docker, these guidelines will surely help you deploy smaller images, and faster.

https://blog.bitsrc.io/best-practices-for-writing-a-dockerfile-68893706c3

2. The competition with Podman is heating up! Docker has recently released a new component: BuildKit, available since Docker 20.10. It dramatically speeds up image build thanks to parallelism, includes better support for passing secrets, and many more features, although not all are enabled by default. Itamar Turner-Trauring explains how to enable them and how to use all of BuildKit in his blog.

https://pythonspeed.com/articles/docker-buildkit/

3. BuildKit is so cool that we are starting to see integrations with other tools. For example, the BuildKit CLI plugin for kubectl made by VMWare enables a shorter build-deploy-test cycle for your containers into your favorite orchestrator platform. If you want to know more about it, read the blog post from Yong Wei Lun and Vadim Bauer from Container Registry.

https://container-registry.com/posts/productivity-lift-buildkit-cli-for-kubectl/

4. One of the biggest missing features in Podman was, without any doubt, the support for Docker Compose. Well, good news! Podman 3.0 includes support for it. Brent Baude from Red Hat explains it all including the required sample code to help you understand how to use it, and also highlighting some caveats (TL;DR: if you use Docker Swarm, it won’t work.)

https://www.redhat.com/sysadmin/podman-docker-compose

5. Do you live in Switzerland, work with containers, and have 5 minutes? Our friends in Netzwoche have published a poll about the container market in Switzerland (in German only). Please provide your answer, and let’s find out what are the current trends for container technology in our country.

https://www.netzwoche.ch/news/2021-02-09/jetzt-bei-der-umfrage-zu-storage-und-container-mitmachen

Are you still using docker or have you migrated to podman completely? How do you optimize the speed of your container build times? Do you have any Dockerfile tips to share with the community? Get in touch with us and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about Containers: #12, #17, #40, #51, #54, and #71.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about a subject we have never covered before in VSHN.timer: cool new hardware for our hobbies and our work.

1. Let’s be honest. We’re all crazy about the Raspberry Pi. You know you want every one of those little boards. And of course the hottest new one in town is the Raspberry Pi Pico, costing just 4 USD, and literally available for free on the cover of this month’s issue of HackSpace Magazine – which, well, it’s already sold out. Have you got yours yet?

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

2. Speaking about the Raspberry Pi, have you built your own Kubernetes cluster with it? In case you’re interested, the Turing Pi 2 has been recently announced! A compact, fast, efficient, and ready-to-use ARM cluster. Supercomputing at home, as they call it. If you can’t wait, the Turing Pi 1 is available for preorder now, with deliveries scheduled for April.

3. One of the most disruptive hardware failures is, without a shadow of a doubt, that of a hard drive. Could we use machine learning to predict those events? Rachel Wenzel from Datto explained how their team did exactly that. TL;DR: it was a fun experiment, but it didn’t quite work. Maybe you should try booting from a vinyl record if all else fails.

https://datto.engineering/post/predicting-hard-drive-failure-with-machine-learning

4. New job? Chinese New Year? Time for a new laptop. And you know that means reinstalling the world again. How can you streamline that procedure? Alabê Duarte shared a simple tip for Mac users: a Homebrew Bundle Brewfile that contains all of your applications and software, ready to be installed in one operation.

https://alabeduarte.com/new-env-setup/

5. Ah, keyboards. The most important element of any hardware setup. The most discussed, loved, hated, used, suffered, and loathed piece of any collection. These days many of us enjoy the benefits of ergonomic keyboards, and split keyboards have become quite popular at VSHN. For that reason we share with you the Awesome Split Keyboards page in GitHub. If you haven’t found the best split keyboard for your home office setup, here’s pretty much the whole market on one page. And if you don’t like split keyboards, check the System76 Launch Configurable Keyboard instead.

https://github.com/diimdeep/awesome-split-keyboards

Did you use this monster-sized, but very comfortable, Microsoft keyboard?#FridayFlashback pic.twitter.com/twT2emJ92A

— Windows Dev Docs (@WindowsDocs) February 12, 2021

How many Raspberry Pi boards do you have at home? How do you deal with hard drive failure? Would you like to share your favorite keyboard with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about the challenges of creating scalable cloud native applications and services.

1. Remember when last year we mentioned Red Hat pushing OpenShift to run 500 pods per node? This time we found another major milestone for Kubernetes: the OpenAI team has made their machine learning cluster to run… 7500 nodes! They provide lots crunchy details and useful information in their article. If your job consists of maintaining complex Kubernetes clusters, you must read this. TL;DR: It works!

https://openai.com/blog/scaling-kubernetes-to-7500-nodes/

2. The recent announcement by WhatsApp to change their privacy policy has made users rush to their competitors: Signal, Telegram, and of course the Swiss-based Threema. How do you cope with such sudden surges in traffic, while maintaining a good user experience across multiple devices? The Threema team explains it all in this fantastic article. Oh! And today is #DeleteWhatsAppDay!

https://threema.ch/en/blog/posts/md-architectural-overview-intro

Join the movement! ✊ Today is #DeleteWhatsAppDay! 🚮

1.) Choose the right messenger: https://t.co/aeCLDOnuMI
2.) Tell your friends: https://t.co/KCAaXzIByR
3.) #DeleteWhatsApp https://t.co/QxSZuwMXj9

— Threema (@ThreemaApp) February 8, 2021

3. Ever heard of the „Trusted Messaging Transfer Protocol“ (TMTP)? It is a secure alternative to the SMTP protocol proposed by Liam Breck with a sample implementation in Go. Learn more about it in his article, and if you are interested, get involved in the project!

https://changelog.com/posts/how-i-volunteered-to-rearchitect-internet-email

4. We don’t even think about them when we browse the web, stream movies on Netflix, or browse our TikTok timeline, but root DNS servers are an absolutely fundamental piece of the Internet. Operating them is as critical as complicated, particularly at a moment when we are moving towards regulation.

https://blog.apnic.net/2020/12/21/the-challenges-of-operating-a-root-name-server/

5. Remember the Unix slogan, „Everything is a file“? What if cloud storage was part of the file system, too? In that sense, the tool of the week is JuiceFS, a distributed POSIX file system built on top of Redis and AWS S3, designed and optimized for cloud native environments.

https://github.com/juicedata/juicefs

But there’s one more thing: bonus item 6! we thought we had to share this one with our readers, so here it goes: the The New Stack published the Top Cloud Native Technology Trends from 2020 and one of them will send shockwaves in the Cloud Native architecture landscape: the return of the monolith!

https://thenewstack.io/the-new-stack-top-cloud-native-technology-trends-from-2020/

Which architecture approach you use in your own infrastructure? Are you moving back to monoliths? Do you have any tips and tricks to share with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about Cloud Native applications and architectures: #25, #34 and #60.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about the latest news around Prometheus and Grafana, our best allies for monitoring Cloud Native apps.

1. How long should you store data in Prometheus? The default of 15 days is due to historic reasons, but Brian Brazil from Robust Perception says that it is totally reasonable to increase that time up to a year.

https://www.robustperception.io/how-long-can-prometheus-retention-be

2. One might think that monitoring and production are completely disconnected systems, yet… Oliver Leaver-Smith from Sky Betting and Gaming tells the story of a monitoring change that had a negative impact in the day-to-day operations of a very popular service.

https://sbg.technology/2020/12/09/its-just-a-monitoring-change/

3. Have you ever written any custom PromQL queries? The language allows for very interesting use cases, but it can look a bit intimidating at first sight. This article by Julius Volz from PromLabs tells you how PromQL queries are structured and evaluated.

https://promlabs.com/blog/2020/06/18/the-anatomy-of-a-promql-query

4. Also from PromLabs, check out the PromQL cheat sheet, build more powerful dashboards, and start getting deeper insights from your data.

https://promlabs.com/promql-cheat-sheet/

5. The tool of the week is grafana-sync, helping you keep your Grafana dashboards synchronized at all times.

https://github.com/mpostument/grafana-sync

Do you monitor systems with Prometheus and Grafana? Have you written your own PromQL queries? Would you like to share some tips with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about specific products and vendors: #61 and #65.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about all those little things that make writing code more efficient, fast, and fun.

1. It might seem pedantic to non-technical folks, but shaving those extra milliseconds in tasks you do every day, well, it all adds up. Take, for example, the startup time of your favorite shell. Developers launch new terminals all the time, maybe on a tab in iTerm2, Windows Terminal, or tmux, and if it takes a bit more than… 100 milliseconds, we go crazy. If you are a Bash user, you will enjoy these guidelines to make your command line appear so fast you won’t believe it.

https://work.lisk.in/2020/11/20/even-faster-bash-startup.html

2. And what do you run in those Bash sessions? Command-line programs, of course. Maybe you have even written some for your own personal use, and then shared some of those on GitHub. In those cases, you might want to read the Command Line Interface Guidelines, a useful (and beautiful!) set of best practices for such applications, including sections about error reporting, arguments, environment variables, and so much more.

https://clig.dev/

3. No matter which editor you spend your life on (Visual Studio Code, Vim, Joe’s, and Emacs are favorites among VSHNeers) you will want to have a nice font for your text, one that is readable in many different sizes, helping you spot errors faster, before you commit that code or hit the deployment button. But there are so many of them! Enter Dev Fonts, a comparison website showing the most common ones, so that you can find your personal choice (disclaimer: my favorite it’s JetBrains Mono).

https://devfonts.gafi.dev/

4. Is it us, or somehow TOML is becoming quite popular lately? We are seeing it more and more as a configuration language of choice in many projects, starting with Hugo, for example. In any case it is great news to see it hit version 1.0 after almost eight years of development!

https://github.com/toml-lang/toml/releases/tag/1.0.0

5. The tool of the week is lightkube, a lightweight Python wrapper around the Kubernetes API. Still a work in development, but one combining two of the most used technologies in VSHN!

https://github.com/gtsystem/lightkube

Have you written and shared any command-line utilities? What is your favorite coding font? Do you have any terminal tips to share with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about code and programming: #18, #30, #33, #47, #50, and #60.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about the most notable security incidents, breaches, tools, and exploits that made the headlines in the past few months.

1. The popularity of Linux in organizations of all sizes comes with a price: attackers are now creating Linux versions of their ransomware. This one in particular, called RansomEXX, targeted businesses and government organizations in the United States and Brazil. A painful reminder that we must keep our defenses high and brace for impact at any time.

2. Speaking about Linux vulnerabilities, the GitHub Security Lab published a step-by-step explanation of a very easy privilege escalation exploit in desktop Ubuntu. We do not know if to be worried about its simplicity, or to marvel at the imagination of the discoverers that found it. At least it didn’t involve kids typing like crazy on a keyboard to make the screen saver crash or something like that. (Say again?)

https://securitylab.github.com/research/Ubuntu-gdm3-accountsservice-LPE

3. In the troubled political times we’re living in, not even DevOps practices are free from risks. Thus we learn that JetBrains‘ TeamCity CI/CD tool was allegedly used as a backdoor in a major supply chain cyberattack targeting American companies and the government. This attack is named „SolarWinds“ after the name of the network management company whose systems were initially compromised. JetBrains later posted a rebuttal of any implication in this scandal, and even if at this point it is very hard to know what’s going on, new details emerge each and every day.

https://www.nytimes.com/2021/01/06/us/politics/russia-cyber-hack.html

4. If not broken, it seems like all software is, at least, breakable. Take iOS, for example. Apple is very proud to brag about its security and privacy features, yet up until a few months ago, you just needed a malformed wi-fi packet to access all the photos of any device, without any restriction. Spooky yet fascinating. It makes us wonder how many other vulnerabilities are yet to be discovered in the devices in our pockets… and how many are being exploited without our knowledge.

https://arstechnica.com/gadgets/2020/12/iphone-zero-click-wi-fi-exploit-is-one-of-the-most-breathtaking-hacks-ever/

5. File this one in the category „Pick Your Jaw Back From The Floor“. This little tool written in Python is able to reverse-engineer pixelated passwords in screenshots, and… yes, you guessed it; just like in the movies, it’s able to recover the text. Add a new item to your honest website security checklist: „never pixelate actual passwords in your screenshots“.

https://github.com/beurtschipper/Depix

Have you suffered a major intrusion or attack in your infrastructure? Which platforms are the most vulnerable to attacks in your experience? Do you pixelate real passwords in the screenshots of your website? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about security: #8, #17, #22, #27, #32, #44, #54 and #62.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about how teams deal with failures, sometimes of seemingly catastrophic proportions.

1. We will start with this gem by Lisa Seelye from Red Hat. It is a mind bending article, providing an answer to the basic question: „Why do we externalize our successes but internalize our failures?“ Failures in systems is a matter of „when“ rather than „if“, and healthy teams, including their management, need to embrace them. And to stop calling those situations „mistakes“ but rather „learning opportunities“.

https://opensource.com/article/20/11/normalize-failure

2. Failure can happen to anyone, even to the biggest IaaS provider on the planet. AWS suffered a major outage of its Kinesis service in the US-EAST-1 region, on November 25th, 2020. And since Kinesis is used by many other major pieces of AWS infrastructure, this failure rippled on other parts of the infrastructure like domino pieces. First Cognito, dealing with user authentication; then CloudWatch, dealing with systems monitoring; and finally Lambda and EventBridge, both of which depend on CloudWatch. The post mortem of this outage reads like a detective novel, the fascinating story of a hard day at the core of the cloud.

https://aws.amazon.com/message/11201/

3. How to deal with failures in OpenShift clusters? The Performance and Scalability team at Red Hat has published a short summary of the three biggest outages they faced in production environments: a rogue DaemonSet taking down a 2000-node cluster, an etcd database that refused to write things down, and the sad results of running etcd on slow storage. Extreme examples for sure, but interesting lessons nonetheless, even though one would rather read about than experience them first hand.

https://www.openshift.com/blog/openshift-failure-stories-at-scale-cluster-on-fire

4. DevOps engineering brings its own load of issues to consider. Take for example the issues related to DNS records, their propagation and validity, and the availability of the systems referenced by them. Blake Stoddard from HEY tells the story of a whole day spent at work „banging his head against the desk“ because of failing to RTFM. In this case the manual was RFC 1034 so please go and re-read it now before you hit that „deploy“ button once again.

5. Raphael Michel from Pretix explains how they solved a data loss failure caused by a video file overwritten by mistake… by grepping the contents of a disk, looking for the header of the FLV video format. Spoiler alert: it took 7 hours, and it’s absolutely epic.

https://behind.pretix.eu/2020/11/28/undelete-flv-file/

How does your team manage failure? Do you keep a log or do you write post mortems after major outages? Do you have any failure handling tips you would like to share with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about incidents and failures: #32, #41, #49, and #66.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

We’re going to start 2021 with a review of some of the latest news on the world of Kubernetes.

1. The biggest news last month was the release of Kubernetes 1.20, including many new features, the most important of which was without any doubt the deprecation of Dockershim. These news were somehow misinterpreted by the community as a deprecation of the whole container concept, and even Kelsey Hightower had to intervene to provide some clarity. In short: you should only be concerned if your workflow requires talking to the Docker socket /var/run/docker.sock, in particular for „Docker in Docker“ type of scenarios. Otherwise, your Dockerfiles and all your containers are still valid and good to go!

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

2. Kubernetes 1.20 brought many other features: volume snapshot operations on supported providers; kubectl debug available in beta; reimplementation of the IPV4/IPV6 dual stack; and graceful node shutdowns, available in alpha for the moment. The official release announcement has more information about these changes.

https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/

3. Deploying to Kubernetes remains a complex experience for newcomers to the platform; in particular, getting your YAML right can take a few tries. To solve this issue, the nice people at Shipa have created Ketch, to deploy your applications to Kubernetes without YAML. Saiyam Pathak from Civo wrote a tutorial to learn how to use it.

https://www.civo.com/learn/deployments-without-yaml-using-ketch

4. Unbeknownst to many, kubectl has an extensive and very useful plugin architecture. Arthur Busser from Padok published a fantastic article with all the information you need to know to not only use plugins, but also recommending some cool ones to install.

https://www.padok.fr/en/blog/kubectl-plugins

5. The tool of the week is the k3d extension for Visual Studio Code, allowing you to spin new clusters directly from your preferred editor.

https://github.com/inercia/vscode-k3d

Are you going to migrate to Kubernetes 1.20? Do you use kubectl plugins? Would you like to share some cool kubectl plugins with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about Kubernetes: #4, #8, #11, #14, #16, #19, #23, #37, #46, #49, #59, and #64.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

For our last edition of 2020, we’re going to showcase some cool Advent Calendars around the web!

1. We cannot start this edition without mentioning the geekiest and one of the most popular of all geek Advent Calendars, the Advent of Code™ (yes, it’s a trademark) by Eric Wastl, creator (among other things) of the lightest, simplest, one and only JavaScript framework you will ever need, Vanilla JS. Solve a new programming problem every day and learn something new! They even have a swag shop with matching t-shirts and other apparel.

https://adventofcode.com/2020

2. Our friends at Puzzle ITC have their own Advent Calendar! It’s Carlo’s OpenSource Advent Challenge 2020. Every day, help an open source project by submitting a pull request or finding bugs. (In German)

3. Another Swiss idea! Our friends at Ungleich have created the IPv6 Advent Calendar 2020 with a new surprise every day. Be quick, offers only available while stocks last!

https://ungleich.ch/u/advent-calendar/

4. We know that many of you are Java developers – after all it’s one of the most used programming languages in the industry! In that case, here’s the JVM Programming Advent Calendar for you, with a new article with tips and tricks for Java developers.

https://www.javaadvent.com/

5. But wait there’s more! If you want to explore other geeky Advent Calendars, for example around JavaScript, PHP, F#, or cybersecurity, the 2020 Roundup of Advent Calendars for Designers and Developers is the resource for you.

https://frontendnexus.com/articles/advent-calendar-roundup-2020/

Do you follow any of these Advent Calendars? Would you like to share your own Advent Calendar with the community? Get in touch with us through the form at the bottom of this page, and see you next year for another edition of VSHN.timer. Thanks a lot for your attention and your support!

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a “thumbs up” to our videos.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about Unix, the family of operating systems powering most of the world today, even if most people don’t even notice.

1. Unix won. The cloud runs on Unix. Virtually all smartphones in the world run on Unix. Probes all around the Solar System run on systems inspired by and compatible with Unix. BSD, Linux, Solaris, and Mac users are all running modified versions of Unix. Windows users can run Unix; and at some point Bill Gates himself said in 1996 that Windows “in a weak sense, it is a form of Unix”. Students can learn about operating systems using Unix. As an architecture, as a philosophy, Unix has become the operating system for the modern world. Developers have embraced the Unix philosophy, but how and when did it come to life? It all happened when a group of brilliant hackers scratched their itch and wrote their own operating system, and even better, shared it with others. Among them there’s Brian Kernighan, the “K” in the K&R book, who recently talked to Adam Gordon Bell about the birth of Unix and how it all came to be.

https://corecursive.com/brian-kernighan-unix-bell-labs1/

2. Developer extraordinaire Amos has written a series of (so far) 13 articles about the structure and inner working of Linux executables, including sample code and step-by-step explanations about many subjects, such as library loading, position-independent code, and much more. We think this should be published as a book, given the depth and breadth, all with a fantastic tone and very easy-to-follow explanations. A delight for all of us geeks out there with time to learn new things during the pandemic.

https://fasterthanli.me/series/making-our-own-executable-packer

3. Invisible to mostly everyone, Linux is undergoing a major change; a migration from interrupt-based to asynchronous event-based I/O. This deep change will have tremendous consequences for the performance of Linux, and its flexibility to handle larger amounts of data in shorter amounts of time. Just like the change to systemd, this change will prepare the road for the future evolution of Linux.

4. 50 years after its birth, Unix is still very big business, mostly thanks to its most successful offspring, Linux. No wonder IBM bought Red Hat in 2018, and this year SUSE snapped Rancher, a core player in the Cloud Native ecosystem. The acquisition is now finished! We congratulate Rancher and SUSE and look forward to keep working with them in the future.

https://rancher.com/blog/2020/suse-day1

5. The tool of the week is cheat.sh, touted as the only cheat sheet you’ll ever need; a unified interface to lots of programming knowledge, all a couple of keystrokes away, including integrations with Emacs, Vim, Visual Studio Code, and whatnot. Brought to you by Igor Chubin, the same person who gave us wttr.in and late.nz.

https://github.com/chubin/cheat.sh

Are you a Linux, Mac, Solaris, HP-UX, or BSD user? Which Linux or BSD distribution is your favorite? Do you think io_uring and eBPF will have such a deep impact in Linux? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a “thumbs up” to our videos.

PS³: check out our previous VSHN.timer editions about Unix and Linux: #45 and #55.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.

This week we’re going to talk about how we’re moving past Docker into a world of open container standards.

1. If you run Docker containers, the lazy option consists in hosting your images in Docker Hub. But beware! They have new download rate limits. In short, Docker Hub now allows up to 100 pulls per 6 hours for anonymous (unauthenticated) IP addresses, and 200 pulls per 6 hours for authenticated non-paying users. Of course, these restrictions do not apply to Docker Hub users with Pro or Team accounts. Our VSHNeer Gabriel Mainberger recently wrote an article in this blog about the measures we had to take due to these new restrictions. We recommend migrating your images to Red Hat Quay, AWS ECR, or to use a private registry, such as Harbor, OpenShift’s or GitLab’s.

https://docs.docker.com/docker-hub/download-rate-limit/

2. Containers are lightweight, fast, and convenient; no wonder they have been embraced by DevOps teams all over the world. There are, however, a few security gotchas to be aware of when writing those Dockerfiles. Cloudberry Engineering has published a useful checklist of eight critical items to keep in mind while creating new images: use trusted base images, do not sudo, do not use root users, avoid curl | bash, and more. They even provided an Open Policy Agent rule to statically analyze your Dockerfiles with conftest! Perfect for your DevSecOps needs.

https://cloudberry.engineering/article/dockerfile-security-best-practices/

3. Did you know that Kubernetes is used by more than half of all organizations using containers? Or that 80% of all Kubernetes clusters in Google Cloud are hosted in the managed GKE service? Or that NGINX, Redis, and PostgreSQL are the most popular container images? The Datadog Container Use Report contains these and eight more interesting facts about the world of containers.

https://www.datadoghq.com/container-report/

4. Podman has slowly but surely become the de facto official replacement for Docker. And migrating to it is as easy as alias docker=podman. Images created by Podman and Docker are both based on the OCI standard, and they are fully interoperable. DevOps engineers also appreciate the simpler architecture of Podman (read: no daemon) for their image building needs. Cedric Clyburn from Red Hat recently wrote a nice blog post explaining all there is to know about this transition. Remember: the industry is moving away from Docker!

https://developers.redhat.com/blog/2020/11/19/transitioning-from-docker-to-podman/

5. The open source project of the week is Bottlerocket, a Linux distribution created by AWS explicitly built to run containers, and an interesting case of using Rust for building a complete operating system.

https://github.com/bottlerocket-os/bottlerocket

Are you using Podman already? Do you check your container images for vulnerabilities? Have you switched to a different image registry? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.

PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.

PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.

PS³: check out our previous VSHN.timer editions about containers: #12, #17, #40, #51 and #54.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about the many changes that the business of software is undergoing in 2020.

1. As our world grows in complexity, experts become more and more important, and sometimes, controversial. But because of the Dunning-Kruger effect, critics do not always realize their own limitations. This article explains this fact with an analogy based on the game of chess, where the difference in skill between a normal players and Grand Masters can be quantified in the hundreds of times. The same happens with expertise; in short: common sense is no replacement for it.
https://didyouknowfacts.com/a-chess-analogy-shows-the-difference-between-expertise-and-common-sense/
2. The current pandemic has brought tremendous change to businesses all over the world. Dropbox decided to adopt a new strategy for its workforce, going „Virtual First.“ What does this mean? In short, it means privileging asynchronous communications, and setting small shared working spaces for their employees, wherever they are in the world.
https://blog.dropbox.com/topics/company/dropbox-goes-virtual-first
3. How are workers reacting to „the new normal“? Atlassian has published a research about the impacts of COVID-19 in remote workers, highlighting the dangers it brings for innovation, recognition, gender biases, inequalities, and group dynamics. A fascinating study.
https://www.atlassian.com/blog/teamwork/new-research-covid-19-remote-work-impact
4. The world of Open Source software has evolved into major business models, like „Open Core“ and „Stable Release“ (aka „The Red Hat Model„). Which one works best? It turns out that for MongoDB, currently the Open Source company with the highest market capitalization (over 12 billion USD), the Open Core model has worked perfectly well. This article explains it all in detail.
https://www.moritzplassnig.com/saas-and-moving-downmarket-mongodbs-transformation/
5. Did you know that in VSHN there are 3 Finns? We have two people in the team with a Finnish passport… and then there’s our dear colleague named, well, Finn. But hey! You can also be Finn for 90 days. An interesting response to the current crisis, opening up new opportunities; live and work in Helsinki for a few months, discover a new life, and maybe even start the next big thing!
https://www.helsinkibusinesshub.fi/90-day-finn/
Will your company pivot to a „Remote First“ strategy when the pandemic is over? Would you move to Finland and work there for 90 days? Have you watched The Queen’s Gambit on Netflix? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.
PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a „thumbs up“ to our videos.
PS³: check out our previous VSHN.timer editions about business: #15, #26, #35 and #41.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about funny things that have an inherent, strong, definitive geek trait to them. Hang tight!

1. Raise your hand if you have ever used Winamp, the player that advocated for mistreating llamas? Raise your hand if you remember what it was like to listen to MP3 files? This being the generation of the streaming music service, I thought I’d ask that first. I personally was more of a Mod4Win user back then (say whaaaaaaa) and these days I’d rather listen to my MP3s with musikcube instead. Yes, in the terminal. Anyway, I digress: if you miss the Winamp days, check out the Winamp Skin Museum! It’ll probably bring back some memories. Le sigh.
https://skins.webamp.org/
2. If you are old enough to have used Winamp, you might also remember that sound modems used to make when connecting to your dialup provider. It turns out there’s a reason for that particular sound, and this blog post contains all the details, including a fantastic poster explaining every element of the handshake, step by step.
http://www.windytan.com/2012/11/the-sound-of-dialup-pictured.html
3. Data compression is a fascinating subject, and we found the best possible resource to learn everything there’s to know about it: The Hitchhiker’s Guide to Compression. Lempel-Ziv, Run-Length Encoding, and Huffman algorithms are included, together with some interactive animations explaining how they work. Excellent!
https://go-compression.github.io/
4. How do you create diagrams? Some of you might use Dia or Visio, but at VSHN we literally write our diagrams as text, using tools like ASCIIFlow Infinity and Kroki. Here’s another cool option is to use, called… well, Diagrams! It allows us to create… you guessed it, diagrams, using 100% Python code. Can’t get geekier than that. Also, the name. Perfect choice, and follows what Sean Kelly suggested: „Name things after what they do“.
https://diagrams.mingrammer.com/

Codenames are for projects, not for services

Name things after what they do
— Sean Kelly (@StabbyCutyou) September 9, 2020

5. The tool of the week is Kube DOOM. This tool takes the „clusters as cattle“ principle to a new level: „pods as video game enemies to shoot down while screaming at your screen.“ What can we say to this? Paraphrasing the catchphrase Marques Brownlee uses at the end of his videos, „Peace!“
https://github.com/storax/kubedoom
Have you ever killed pods or whipped llamas? Do you write your diagrams as text or do you draw your prose with images? Do you have any other funny geeky thingies to share with the community? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter.
PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a thumbs up to our videos.
PS³: check out our previous VSHN.timer edition #36 about random funny stuff.

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about the latest news of that other project named after Linus.

1. Git users are familiar with those typical 40 hex character-long hashes generated by Git, uniquely identifying a commit across time and space. Uniquely? Well, to a certain extent. Since the beginnings Git generates those hashes using the SHA-1 hashing algorithm, but a few years ago researchers found a way to break it. Since then, the Git project maintainers have started a transition towards SHA-256. Git version 2.29, released only a few weeks ago, is the first one implementing experimental support for this new hashing algorithm: try it out with git init --object-format=sha256 repo. Be aware of the experimental word before you start using it in production, though.
https://github.blog/2020-10-19-git-2-29-released/
2. Inexperienced users of Git might inadvertently deploy their applications to production servers together with the .git folder, the one that contains the whole history of your Git repo. Yes, the same one including all the stuff you once wrote and the deleted, like passwords and security keys, because Git never forgets anything. And, lo and behold, curious and entrepreneurial researchers have found those folders all over the place, and of course, started downloading them, and examining their contents, many of which were, of course, confidential. Another case of severe DevOooops. Now you can do that too, thanks to Gitjacker.
https://www.zdnet.com/article/new-gitjacker-tool-lets-you-find-git-folders-exposed-online/
3. For a long time big firms have been reluctant to adopt open source software and DevOps practices, justifying those decisions on arguments of trade secrecy and security. But the competition is stronger than ever, and even the biggest of banks in the Paradeplatz are ready to jump on the train. Take for example the case of UBS, now actively using GitLab to help their teams release better software to their users, and more often than ever. (Article in German.)
https://www.netzwoche.ch/news/2020-08-27/ubs-setzt-auf-devops-plattform-von-gitlab
4. Have you heard of git summarize-subtree? It is the Git command that summarizes all applied subtrees outside the format-patched non-failed applied archives. What about git split-ref? It is used to split any non-applied upstream refs over various bundled remote indices, which can happen whenever git manufacture-head manufactures the non-pushed local heads outside some stashed subtrees, and the --nick-race-upstream diffs a ref for the subtree that is bundled by a staged stash. Excuse me, what? How can one keep up with so many Git commands and options? Fear not, the previous examples come from the fake Git man page generator! For reference of actual Git commands, you might want to refer to Dangit, Git!?! instead.
https://dangitgit.com/
5. The tool of the week is GOMP, the Git cOMPare tool, a nice app written in Python to compare Git branches in the command line. A great way to prepare releases and fixing conflicts!
https://github.com/MarkForged/GOMP
How much does your team depend on Git? Are you using some other SCM tool? Would you like to share any pro Git tip with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter!
PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a thumbs up to our videos!
PS³: check out our previous VSHN.timer editions about Git: #48 and #10!

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about how we can grow in our careers through education, from complete beginners to absolute masters in the arts of DevOps.

1. How does one become a competent DevOps engineer? This profession is so new that it baffles recruiting managers and engineers alike. (Ever seen a job offer asking for 10 years of experience in Kubernetes? Been there, seen that.) How much experience is enough experience? What is the optimal path for those interested in following this career? The people behind roadmap.sh have come up with a fantastic flowchart with plenty of recommendations, ready to be followed. (And by the way, did you know we’re actively looking for DevOps engineers? Apply today!)
https://roadmap.sh/devops
2. To be an effective DevOps engineer, one needs very good practical knowledge about networking. The Low-Level Academy has started publishing an excellent set of interactive tutorials about the subject. Right now they have published tutorials about number encoding, UDP, and packet fragmentation. Coupled with „Beej’s Guide to Network Programming“, the Low-Level Academy will flood your brain with interesting packets of information. Stay tuned for more!
https://lowlvl.org/
3. Before the sanitary crisis we’re living in, getting certified consisted in sitting down and answering questions under controlled conditions; usually under surveillance and following a standardized process ensuring fairness and objectivity. How to do that during the pandemic? Red Hat has decided to adapt and launched online options for four of its exams: RHCSA, RHCE, and two OpenShift curricula. Get certified from your own home!

4. The devices of DevOps engineers scream for attention every second. Prometheus notifications, new blog posts over RSS, discussions on Twitter, Hacker News and Reddit articles… it is hard to keep up, and there’s a high risk of productivity drop. Ben Kuhn has published a set of simple, practical steps to sharp our tools and pay attention to that which actually matters.
https://www.benkuhn.net/attention/
5. Is the lack of education a security risk in a knowledge-based society? It definitely is. Unaware employees inadvertently give away passwords or other private information to strangers. Social engineering is on the rise, and more and more companies are struggling to keep up with this type of attacks. The first and most important line of defense is education: teach your collaborators that the risk exists, and that they need your utmost attention. Share this article with them to get started in this process.
https://www.freecodecamp.org/news/social-engineering-the-art-of-hacking-humans/
What are your preferred methods of learning? Have you passed a certification exam lately? Would you like to share any tips and tricks with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Subscribe to our VSHN.timer newsletter!
PS²: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and like our videos!
PS³: check out our previous VSHN.timer editions about education: #21 and #38!

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about noteworthy outages and availability issues that brought SLAs to their knees.

1. Let’s play some Jeopardy!, shall we? „Cloud services for 1000!“ „It happened to GitHub, Zoom, Slack, IBM Cloud and T-Mobile during the pandemic.“ You hit the buzzer and scream the right answer: „What is an outage?“ Unfortunately all of these services had at least one major outage this year. It makes us remember how fragile online services can be under stress, and yes, that not even the biggest names in the industry are immune to failure.
https://statusgator.com/blog/2020/08/21/5-biggest-outages-of-q2-2020/
2. Sometimes Murphy’s Law hits so hard, it’s almost unfathomable. Take, for example, Basecamp, the popular project management service. They had three consecutive outages on the same week. What are the odds? The important takeaway in the post mortem is not so much the measures and countermeasures they took, but the timely communication and the openness to say „I’m sorry“ to their customers.
https://m.signalvnoise.com/three-basecamp-outages-one-week-what-happened/
3. Speaking about post-mortems, some teams take the time to write some really comprehensive ones, documenting every single detail about what happened. It makes for a fascinating read and provides fantastic information for teams preparing for (or suffering) such events.
https://signal.eu.org/blog/2020/09/09/post-mortem-of-a-dnssec-incident-at-eu-org/
4. Application developers are eternal optimists by nature. The default values in many programming languages and frameworks literally specify „infinite“ as a timeout. Developers, instead, must learn how to deal with flaky networks that can fail at any time. Roberto Vitillo from Microsoft urges software developers, both on the front and backend, to override the default timeouts, and gives some useful examples of how to do that.
https://robertovitillo.com/default-timeouts/
5. The tool of the week is Crowdsec, „An open-source, lightweight agent to detect and respond to bad behaviours.“ The idea can be summarized as a next-generation firewall aiming to achieve „digital herd immunity“ for cloud services. Their website has an interesting list of objectives for the coming years, including the addition of machine learning to thwart attacks before they even happen. To say that this is intriguing would be an understatement.
https://github.com/crowdsecurity/crowdsec
Is your infrastructure ready to handle outages? Do you have a status page for your customers? Would you like to share any war stories with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Subscribe to our VSHN.timer newsletter!

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about one of our preferred tools in our DevOps arsenal, Terraform, and how it has become a platform full of interesting projects and frameworks.
1. Here in VSHN we breathe infrastructure as code. It is no surprise that we are great Terraform fans! We were very curious to learn about Terraspace, a Terraform Framework (yes yes, that’s a thing!) helping DevOps engineers to be more productive. You can use it for example to deploy multiple stacks at once in various cloud providers with just one command, regardless of the number and structure of their dependencies. Really impressive stuff.
https://blog.boltops.com/2020/09/19/terraspace-all-deploy-multiple-stacks-at-once
2. Most younger DevOps teams will require, however, a more gentle introduction to the outstanding powers of Terraform. You can use it to configure and deploy a whole Kubernetes cluster in Azure, for example.
https://codersociety.com/blog/articles/terraform-azure-kubernetes
3. Paraphrasing a famous song, Terraform and Kubernetes live together, in perfect harmony, side by side on our keyboards. Thanks to Kubestack, another Terraform framework, teams can automate the deployment of K8s clusters in AWS, Azure or Google Cloud. Clusters as code!
https://www.kubestack.com/
4. Kubestack and Terraspace are not the only frameworks built on top of Terraform; there’s a whole ecosystem out there! HashiCorp themselves have published their own Kubernetes Operator for Terraform, providing yet another mechanism to connect both worlds.
https://github.com/hashicorp/terraform-k8s
5. Terraform configurations are usually written using the HashiCorp Configuration Language or JSON. But thanks to the Terraform CDK you can use TypeScript, Python or even Java to define your infrastructure as code. And now you’ve run out of excuses.
https://github.com/hashicorp/terraform-cdk
Is your infrastructure defined as code? If so, how much of it? Would you like to share any tips with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Subscribe to our new VSHN.timer newsletter!

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about the latest news about our favorite container orchestrator, like, ever.
1. We’ve talked about Kubernetes Operators previously, but DevOps engineers are still puzzled about them; in short, when to use them? This fantastic article in The New Stack will help you decide.
https://thenewstack.io/kubernetes-when-to-use-and-when-to-avoid-the-operator-pattern/
2. How do you manage secrets in Kubernetes? This article reviews several options (Vault, Mozilla Sops, Bitname Sealed Secrets) and dives into GitOps with Kapitan, which is the tool we use at Project Syn, by the way.
https://medium.com/kapitan-blog/declarative-secret-management-for-gitops-with-kapitan-b3c596eab088
3. We recently discovered Artifact Hub and we love it. It is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects. Check it out!
https://artifacthub.io/
4. YAML much? Give this generator a spin. You’re welcome.
https://k8syaml.com/
5. The tool of the week is a collection of ready-to-use Kubernetes scripts that might save your life anytime soon.
https://github.com/eldada/kubernetes-scripts
What other tools do you use in your Kubernetes life? How do you manage those YAML files? Would you like to share any tips with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Subscribe to our new VSHN.timer newsletter!

Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about the inner working and well-being of the minds of DevOps engineers. By the way, this edition borrows its title from the 1971 classic book „The Psychology of Computer Programming“ by Gerald Weinberg, a timeless classic, the first ever book about PeopleOps.
1. This year has been (and still is) one of the most complicated of our existence. We are all feeling it. The pressure. The abysmal news on our screens. The concerns about our families. Lock-downs. Masks. The struggle. It is time to remind ourselves that it’s OK to say that we’re not OK.
https://its-ok.clearleft.com/
2. How are those DevOps engineers doing in your company? If you are in charge of a technical team, please read this guide by Kat Boogaard from Trello, and make sure your colleagues are not on the verge of a breakdown.
https://blog.trello.com/spot-signs-of-team-overwhelm
3. Senior software engineers know that one of the most complex skills to learn is that of reading code properly. Why do we find some pieces of code easier to read than others? How can we make life easier for our colleagues? How does it all work? Egon Elbre recently wrote a comprehensive article full of insight about the subject.
https://medium.com/@egonelbre/psychology-of-code-readability-d23b1ff1258a
4. Growing up into senior engineers means leaving behind our egos, cultivating empathy, and getting rid of hubris. In a world where every company is a software company, and where this includes the humblest of corner shops, it is time to agree that ‚real‘ programming is an elitist myth.
https://www.wired.com/story/databases-coding-real-programming-myth/
5. Thankfully more and more companies agree that the well-being of their engineers translates directly into great products. Our friends and partners at amazee.io have recently shared an interview with two of their system engineers, Bastian Widmer and Thom Toogood, and it’s great to have an insight into their culture.
https://www.amazee.io/blog/post/life-as-a-systems-engineer-at-amazee.io
How are you and your colleagues doing? How do you take care of one another? Would you like to share any tips with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Subscribe to our new VSHN.timer newsletter!
PS (again): We have published quite a few VSHN.timer entries dedicated to the subject of PeopleOps, check them out: #7, #13, #15, #26, #35, #41  and #52.