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 YAML, the markup language that’s driving most of the cloud native app world.
1. YAML is everywhere. 15 years ago it was mostly found in configuration files for Ruby on Rails apps. Nowadays? Crazy. Docker Compose? Check. Kubernetes deployments? Check. Ansible playbooks? Check. Antora playbooks? Check (although these can also be written in TOML, did you know?) GitLab CI/CD pipelines? Check. Azure pipelines? Check. Great! Right? No, not really; Martin Tournoij has kept a very interesting list of awful YAML facts well worth a read.
https://www.arp242.net/yaml-config.html
2. Many of us are quite happy with the YAML plugin by Red Hat for Visual Studio Code, but if you are a Vim user busy editing Kubernetes configuration files day and night, this article will certainly make your day.
https://octetz.com/docs/2020/2020-01-06-vim-k8s-yaml-support/
3. We always wanted to write a clickbait headline in a VSHN.timer article, so here it goes: „How many ways are there to break a multi-line string in YAML? The answer might surprise you.“
https://stackoverflow.com/a/21699210
4. The hatred towards YAML made Geoffrey Huntley create an anti-YAML manifesto… written in YAML. Extraordinary.
https://noyaml.com/
5. If you reached the point of YAML saturation, you might want to give the CDK for Kubernetes a try. It helps you write manifests using Python and TypeScript instead of YAML. Because no problem can’t be solved with yet another level of abstraction.
https://cdk8s.io/
Does your team get along well with YAML? Or have they wrapped it with yet another abstraction layer? Do you have any 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.

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 to efficiently collaborate in (and with) distributed teams.
1. The current global pandemic has forced businesses of all kinds to adopt remote collaboration patterns in their teams. This does not always work, but thankfully some teams have been sharing their best practices lately. Michael Müller from Container Solutions explains how communication, collaboration, and coordination are impacted when working remotely.
https://blog.container-solutions.com/how-to-manage-distributed-teams-even-when-you-have-no-choice
2. The title of this article might sound a bit click-baity, I give you that; but we can all agree that this unprecedented situation has somewhat changed our habits. Microsoft has a strong contender in the remote collaboration tool space with Teams, quickly catching up with Zoom–not only in features, but also in security incidents, sadly.
https://www.theverge.com/2020/4/9/21214314/microsoft-teams-usage-coronavirus-pandemic-work-habit-change
3. Speaking about Zoom, no, we’re not going to repeat again and again that long list of security issues. No, this time we’d like to pay attention to the effects of conference calls in our psychology. Zoom calls can be exhausting and can drain your energy. This is so pervasive and important that we’ve even added a page to our Handbook about that.
https://theconvivialsociety.substack.com/p/a-theory-of-zoom-fatigue
4. This whole situation should remind us all that we’re humans, and that we can make mistakes. Take for example Cloudflare’s outage last month, apparently caused by „remote hands“ during a maintenance window, affecting many critical services.
https://www.itnews.com.au/news/remote-hands-flub-takes-out-much-of-cloudflare-546752
5. Hype is a problem, not only in technical circles, but actually even more in management, where trends and fads come and go in a blink of an eye. The „Scaling Agile @ Spotify“ paper had made lots of noise back in 2012, but it appears that the truth is much more complicated than that. Jeremiah Lee wrote an interesting rebuke of the Spotify model that you might want to read.
https://www.jeremiahlee.com/posts/failed-squad-goals/
How have you been impacted by the current situation? Have you modified your organizational structure to cope with this pandemic? Do you have any 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.

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 to create better, faster, smaller containers for the cloud applications you deploy every day (or even better, several times a day!)

1. As containers reach the „plateau of productivity“ in the hype cycle, developers are more and more interested in making their applications leaner and faster. Jérôme Petazzoni wrote an incredible series of three articles (a joy to read) explaining all one needs to know to make our containers smaller. And when he says smaller, he means it; something like 99.9% smaller! Recommended to beginners and experts alike.

https://www.ardanlabs.com/blog/2020/02/docker-images-part1-reducing-image-size.html

2. Guillaume Grossetie, busy cranking out new versions of the awesome Kroki, applied all the tips and tricks proposed by Jérôme (and many others) and documented the whole process, including lots of useful links.

https://blog.yuzutech.fr/blog/minimal-docker-containers/

3. By this time most of the readers of this series are probably building their containers with Podman exclusively, or at least have added a line reading alias docker=podman to their dotfiles. Either way you might be interested in the inner workings of rootless Podman builds combined with Buildah, including networking and storage requirements usually only available to processes running with higher privileges.

https://www.redhat.com/sysadmin/behind-scenes-podman

4. Sometimes Kubernetes is „too much;“ in those cases, Docker Compose is the usual simpler alternative to „orchestrate“ containers. If that’s your case, you might find the Docker Compose Package Manager a handy tool to share your configurations in other contexts, or with other users.

5. The tool of the week is Paketo Buildpacks, a CNCF sandbox project started by the Cloud Foundry Foundation. It provides a high-level abstraction to create container images, with ready-to-use language packages for popular stacks such as .NET, Java, Go or Node.js.

https://paketo.io/

Do you care about the size of your containers? Do you use Podman instead of Docker? Do you have any other 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.

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 Kubernetes operators… and that famous song, which some of you will have stuck in their heads for days to come thanks to the title of this post.
1. Two weeks ago we mentioned that Kubernetes is raising the abstraction level for DevOps. For the past three years since their introduction, operators have been leading the way in this upwards movement. As a reminder, Operators are custom controllers extending Kubernetes to create, configure, and manage instances of complex apps. At the time of this writing, OperatorHub.io lists over a hundred operators, providing Day-2 management support to DevOps engineers all over the world. In the meantime, engineers learnt and identified common issues and best practices for operators. What makes, then, a good Operator these days? Alex Handy from Red Hat recently summarized it in a detailed blog post.
https://www.openshift.com/blog/what-makes-a-good-operator

I’m sure this will upset somebody, but OLM and Operator Hub should go away. It’s creating unnecessary fragmentation in the space. Operator is a polluted term, but it’s here to stay. The unit of management is not an operator, it’s a helm chart. The ecosystem has spoken.

— Darren Shepherd (@ibuildthecloud) April 18, 2020

2. Some companies are actively harnessing the power of Kubernetes operators. Here at VSHN we have published some, for example our legendary K8up backup operator, the Espejo operator, and more recently the upcoming Project Syn’s Lieutenant operator. Another well-known operator fan is the Banzai Cloud team, who recently introduced version 3 of their now ubiquitous Logging operator.
https://banzaicloud.com/blog/logging-operator-v3/
3. The Banzai Cloud team recently released the new Thanos Operator, whose main task thankfully isn’t to snap its fingers and delete half of your deployments. Quite the opposite, indeed; Thanos extends Prometheus with long term storage and querying capabilities, allowing DevOps engineers to be able to monitor multiple cloud environments in the easiest possible way.
https://banzaicloud.com/blog/thanos-operator/
4. Red Hat strongly supports the Kubernetes operator ecosystem. The Red Hat Communities of Practice regularly publish new, useful, and open-source operators showcasing novel uses. Take, for example, operators for Namespace Configuration, Quay, or Cert-Utils. Even better, check out the Operator Utility Library, itself written on top of the Operator SDK to help developers write better and smoother operators.
https://redhat-cop.github.io/
5. The tool of the week is the DBaaS Operator by amazee.io, whose name that says it all.
https://github.com/amazeeio/dbaas-operator
Do you use deploy operators in your clusters? Do they help you in your day-to-day work? Have you published any operator 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.

Welcome to another VSHN.timer! Every week, 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 review some learning resources online; maybe we can turn this crisis around as an opportunity to learn something new?
1. If you are reading this blog post, chances are there’s a Kubernetes cluster near you, innit? Well in that case you’ll find the Kubernetes Built-in Controls Workshop exercises very useful. Hands-on training to learn how to secure your clusters, applying the best possible settings to your infrastructure. Of course, if Kubernetes isn’t (yet) your cup of tea, try the Illustrated Children’s Guide To Kubernetes first. That will help you getting started for sure.
https://securek8s.dev/exercise/
2. Readers of VSHN.timer know how much we VSHNeers enjoy playing with our Raspberry Pi computers (and other similar SBCs.) Here’s a nice walk-through by Alex Ellis to get a Kubernetes cluster in your Raspberry Pi in 15 minutes. But if you’ve already been there, done that, then meet the four-slot Raspberry Pi cluster board, with a starting price of USD 80. Have fun building your own household-scale cloud service!
https://medium.com/@alexellisuk/walk-through-install-kubernetes-to-your-raspberry-pi-in-15-minutes-84a8492dc95a
3. Security is a complex topic, and more important than ever. Enter Cryptohack, an online platform to learn cryptography: learn protocols and algorithms, solve challenges, and earn points! A fun way to learn more about this crucial subject. Also worth mentioning: the be[a]ware team is spreading the knowledge of security and privacy to younger students in Switzerland. Great job, check their website!
https://cryptohack.org/
4. Did you know that Red Hat is offering some of its official courses completely for free for the time being? For example, you could learn about OpenShift or RHEL using the official curriculum. Why not starting today?

5. There are lots of Kubernetes client applications beyond the venerable kubectl. Today we’d like to suggest newcomers to start with Lens, an open-source and free IDE offering a great overview of your deployments, services, everything running in your cluster. A must have in your arsenal for sure.
https://k8slens.dev/
What other things (tech or non-tech) are you learning these days? Would you recommend us other learning platforms? 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.

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 stretching Kubernetes in all directions, testing its capacity and resilience. Ready for a workout?
1. Red Hat is pushing OpenShift to the limits. They recently achieved the impressive milestone of running 500 pods per node. Not just „hello world“ kind of pods, but rather actual workloads that teams actually need. We’re big fans of OpenShift at VSHN, from offering APPUiO to our customers, to running CodeReady Containers in our laptops, and this one made us drool. The article contains the full description of the hardware, software, and configuration settings required to do this.
https://www.openshift.com/blog/500_pods_per_node
2. The analogy of pets vs. cattle for cloud service management goes way back, apparently as back as 2006. But now in 2020, as we move up in the abstraction hierarchy, it is now time to start treating Kubernetes clusters as cattle; for example, with Project Syn. Thanks to Kubernetes‘ flexibility, having a single team managing many different Kubernetes clusters is not unheard of. Enter Rancher Fleet, a new product aimed specifically for this task, and a natural step for Rancher, given the wild popularity of K3s.
https://rancher.com/blog/2020/fleet-management-kubernetes/
3. Speaking about moving upwards the abstraction hierarchy, Helm is a great example. But Helm begat Helmfiles. Which begs the question, how to best start the development of our own Helm charts and Helmfiles? Paul Czarkowski has distilled a starter kit of very opinionated best practices and templates just for that. A great resource to help us stand on the shoulder of giants.
https://github.com/paulczar/helmfile-starter-kit
4. Whoever has to work concurrently with a myriad of Kubernetes clusters (remember, the new cattle) feels the pain. Switching from one kubectl (or oc) context to another can quickly become a hassle. Hence Kubie by Simon Bernier St-Pierre; a tool created specifically to solve that problem. And now your local Minikube test cluster is just a kubie ctx away.
https://blog.sbstp.ca/introducing-kubie/
5. The tool of the week is pgsync, a tool by Instacart to sync data between PostgreSQL databases, designed for speed, security, flexibility and convenience.
https://github.com/ankane/pgsync
How many clusters do you currently run and/or manage? What other tools or techniques help you and your team do that? 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.

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 mashup a quick bric-à-brac of stuff we found online. Maybe there’s a hidden theme across all these links?
1. Do you know what is the Maximum Transmission Unit in a standard Ethernet network? 1500 bytes. Wait, isn’t it a power of 2? Ben Cox explains the whole story behind that number, telling a story of economics, politics, and standards, and showing how it affects the efficiency of today’s Internet. We still struggle to find out WTF is our IP address, though.
https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500
2. Distributed systems require distributed consensus algorithms. Paxos and Raft are quite popular these days. Other examples are ZAB, Blockchain, and DNS. But which of all these is the most widely used, distributed, and cross-platform of them all? Jens Finkhaeuser has a different answer for this question and it will surprise you (or not!)

3. Thinking about making that internal tool an open source project? You might be starting a longer trip than you thought at first. Making your private GitHub repository visible to everyone is just the first step. Matthew Rocklin explains what the other six steps consist of; yup, seven stages in total.

4. The beauty of Unix lies in its philosophy; its wide variety of flavors, its iconic command line, and its infinite flexibility to allow us to solve problems in the most unexpected ways. Of course that variety can be overwhelming sometimes; the Rosetta Stone for Unix is a fantastic map to find your way from BSD to macOS to Solaris to Linux and beyond. HP-UX, anyone?
http://bhami.com/rosetta.html
5. The tool of the week is TEXTREME, a text editor that fits perfectly with your noisy hacker keyboard (blue switches FTW!) and with the current „work from home“ theme. Pump up the volume and write that blog post! Well, until your significant other or your neighbor complain about the noise.
https://le-von.itch.io/textreme
So, what do you think? Can you spot the hidden theme across these links? Would you like to share some more random stuff 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.

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 are going to do an overview of the best practices, ideas, and books about working from home that we have found so far.
1. We start by what we think is probably the best article published so far about the subject. Alice Goldfuss, who has had lots of experience in remote working, not only provides practical tips about your setup (office layout, furniture, equipment, etc.) but also about the emotional stress caused by being on your own. Her advice is timeless, but never as timely as today. Simply extraordinary reading.
https://blog.alicegoldfuss.com/work-in-the-time-of-corona/
2. In a similar vein, but with a much more practical point of view, Marion enumerates a list of things to keep in mind while working from home in these troubling times. Habits, attitudes, timings, food, it’s all there. A simple but effective checklist for our daily well-being.
https://dev.to/codeidoscope/top-tips-for-working-from-home-8md
3. Of course software vendors are actively trying to transform this crisis into an opportunity. It is certainly the case of Zoom, whose shares are skyrocketing as we speak. In any case they have published a blog post full of useful tips and tricks for working from home. It includes some technical guidance for webcams and microphones, for the sake of sane online meetings. In VSHN we use Zoom every day! We meet at 9 in the morning, while we enjoy a cup of coffee or tea, and later as well, at 4 in the afternoon, before the day finishes. These meetings help us keep in touch with one another, and work better as a team. By the way, we informally call the 9 AM Zoom meeting a „Znoomi“, because it is a mix of Zoom and a znüni… Swiss German readers will understand! 🙂
https://blog.zoom.us/wordpress/2020/03/09/working-from-home-tips-to-meet-like-a-pro/
https://twitter.com/vshn_ch/status/1239589997440884736
4. Are you curious about other people’s home offices? Jason Fried from Basecamp asked his colleagues to send him a picture of their desktops, and the resulting collage is quite a sight. Tip: scroll to the bottom!
https://m.signalvnoise.com/remote-working-the-home-office-desks-of-basecamp/
5. The tool of the week is the Microsoft Live Share extension for Visual Studio Code, allowing teams to remotely share pair programming or training sessions. Think SubEthaEdit but cross-platform and with all the debugging prowess of a great editor. And of course it also works with VSCodium!
https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare
6. But there’s One More Thing™®©: since many of you are stuck at home, and might want to have some book recommendations, here’s ours for this week: „The Year Without Pants: WordPress.com and the Future of Work“ by Scott Berkun, and „REMOTE: Office Not Required“ by (once again) Jason Fried and David Heinemeier Hansson. Bonus points: at the time of this writing, Scott’s book is available for free in its Kindle edition, while REMOTE is available for free on Audible. Check them out!
https://scottberkun.com/yearwithoutpants/
How are you balance your personal and working life? What other tools would you recommend ? 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.

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 always talk about cool things that (supposedly) work. So this week we decided to to talk about those things that don’t really work that well. Because, let’s be honest, that’s how it goes sometimes.
1. Go is the language of the cloud native world, and it certainly incorporates some radical, if not controversial, design choices. Amos, for one, wholeheartedly disapproves of it, and would be very glad to stop using it altogether. He has some strong arguments to back his opinion. And in related news, we learnt this weekend that GolangCI.com is closing down.
https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
2. „The best is the enemy of the good.“ Conway’s law. Murphy’s law. Brook’s law. Knuth’s optimization principle. All adages created to remind us that, as system designers, we often are our own worst enemies. Against the madness of hype, microservices, programming languages „à la mode,“ and other crazy stories, Greg Kogan reminds us that simple systems have less downtime, aptly using large container ships as an example. Because… containers. Duh.
https://www.gkogan.co/blog/simple-systems/

Ships contain simple systems that are easy to operate and easy to understand, which makes them easy to fix, which means they have less downtime. An important quality, considering that “downtime” for a ship could mean being stranded thousands of miles from help.

3. Ahh… Kubernetes. It runs on our container platform, it runs on our laptops, it runs on our hobbies, and even in our coffee machine. Yeah, not really. Well, not yet at least. Of course not everybody is happy with this state of things, like Itamar Turner-Trauring, who wrote an article whose title says it all: „“Let’s use Kubernetes!” Now you have 8 problems“
https://pythonspeed.com/articles/dont-need-kubernetes/
4. Case in point: the Flant team shared their (bad) experiences with the Redis operator for K8s in an article with astonishing detail. Must read if you are using it.
https://medium.com/flant-com/redis-kubernetes-operator-and-data-analysis-tools-afce55b02123
5. The tool of the week is Bottlerocket OS, a Linux-based operating system designed to run containers. Hopefully you’ll deploy simple systems with it!
https://github.com/bottlerocket-os/bottlerocket
What parts of the cloud native world give you headaches? How do you manage the complexity of your systems? Any tool you might want 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.

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 are going to talk about useful tips and tricks for writing shell scripts. However, given the current situation of the COVID-19 outbreak, we wanted to start this edition of VSHN.timer linking to the official recommendations for workplaces of the Swiss Federal Office of Public Health. Last week we shared in this blog our own measures, based on those guidelines. Stay safe!
1. Shell scripts are very convenient; they are portable and available off-the-box across Unixes, but they can also be tricky to write correctly. This can lead to common bugs, and most problematic, security issues, which can be particularly nasty in the age of containers. To avoid bad surprises, the MIT Student Information Processing Board has published a series of recommendations for safer shell scripts.
https://sipb.mit.edu/doc/safe-shell/

Want to stop people running SELECT * on a table?

Add a virtual column returning an error, such as divide by zero:
alter table t
add zero_divide int as ( 1/0 );
select * from t;
ORA-01476: divisor is equal to zero#SQL
— SQL Daily (@sqldaily) February 28, 2020

2. We have already referenced this one, but here it goes again: the ultimate Bash scripting cheatsheet. Must. Have.

3. Going a step further than a simple cheatsheet, the Unix Toolbox is an outstanding collection of Linux / Unix / BSD commands, neatly organized by topic, highlighting the major differences between Linux and BSDs. Fantastic, timeless resource.

4. If you use Ansible and need to interface with it with Python, you will most probably need Ansible Runner. Jan-Piet Mens wrote an extensive blog post showing how to use it and integrate it with other systems.
https://jpmens.net/2020/02/28/dial-a-for-ansible-and-r-for-runner/
5. The tool of the week is ShellCheck, a fantastic lint for shell scripts, featuring integration with the most popular editors. It’s like having an expert proofreading your code and pointing most common mistakes, and providing suggestions! And if you would like to learn more about how it was written, this blog post by its author will provide answers to all your questions.
https://www.shellcheck.net/
What other tools would you recommend? What programming languages do you write your scripts with? 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.

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.
In an increasingly volatile and uncertain world, it seems to us appropriate to spend some time talking about security and incident management this week.
1. Last month was full of news about web browser security. First let’s talk about Safari; Apple has decided to consider invalid all security certificates older than 13 months. This is a strong move, geared „to improve website security by making sure developers use certificates with the latest cryptographic standards.“ There is a possibility that other browsers might do the same in the near future. As for Firefox, in the meantime they decided to enable DNS over HTTPS, for US users at least.
https://www.schneier.com/blog/archives/2020/02/firefox_enables.html
2. Always remember to update your browsers to the latest versions. Last week Google released a new version of Chrome with three security fixes, one of which (CVE-2020-6418) has already been exploited. In any case, Brave has been found to be the most private browser, so you might want to switch if you have any concerns.
https://www.ghacks.net/2020/02/25/study-finds-brave-to-be-the-most-private-browser/
3. Speaking about vulnerabilities, CVE-2020-0688 was published last week and describes a „Remote Code Execution on Microsoft Exchange Server Through Fixed Cryptographic Keys,“ due to a bug in the installation process of Exchange, leading to non-unique keys being generated. But the problem is deeper than that; e-mail is unsafe, and cannot be made safer, not even through encryption.
https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html
4. One of the biggest issues in software engineering, and decidedly an endless source of security issues, is requirements volatility. Charles R. Martin wrote about this problem in the Stack Overflow blog, highlighting the role of incremental development processes to help developers manage this volatility. The article mentions a few historically relevant papers; if you are into reading them, you will enjoy the latest one by Bertrand Meyer and others, about, precisely, the anatomy of requirements.
https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/
5. The tool of the week is Dispatch, a system created by Netflix to help them handle security incidents and streamline crisis management throughout their organization.
https://github.com/Netflix/dispatch
What tools do you use to manage security incidents? What best practices do you consistently apply in your organization? 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.

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 are going to talk about common lessons learnt by DevOps teams, shared with the world so that we don’t make the same mistakes over and over again.
1. The best Ops teams share war stories with each other all the time; they are the lessons learned, grinding teeth against platforms and vendors. Jan Schaumann compiled the 88 most important of those lessons in an article with too many pearls to pick just one: management, finance, technical issues, they are all there. To read, re-read and share.
https://www.netmeister.org/blog/ops-lessons.html
2. In what is probably one of the most widely shared articles in this beginning of the year, Mathias Verraes explains a rational approach to manage technical debt. An article helpful for developers and managers alike.

3. Kubernetes is the new standard, but one with many facets and complexities. Teams looking into migrating their cloud native workloads to Kubernetes face lots of decisions, but thankfully Kevin Casey has written down the 6 secrets for success with Kubernetes. And since you’re at it, you might want to stop using Docker to build your containers as well.
https://enterprisersproject.com/article/2020/2/kubernetes-6-secrets-success
4. Of all the many contributions of Git to the software industry, GitOps is the latest. Dewan I A., developer advocate at IBM, explains how to use GitOps with OpenShift 4.x together with ArgoCD, with a very clear step-by-step explanation.
https://www.linkedin.com/pulse/openshift-4x-foundations-getting-started-gitops-dewan-i-ahmed/
5. The tool of the week is OneDev, an all-in-one DevOps platform, including features such as source code repository, CI/CD pipelines, issue boards, and code discussions, in a single integrated package. Already in version 3, it appears as a solid option for teams looking for a free, open source platform for automating their workflows.
https://github.com/theonedev/onedev
What lessons have you learnt in your DevOps journey? What best practices do you consistently apply in your team? 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.

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 are going to talk about programming languages, known and unknown, old and new, and how they fit in a cloud native world.
1. Ahhh… programming languages. The bread and butter of software developers all over the world. The endless source of discussions, preferences, rants, praise, and arguments. In the world of containers and cloud native apps, though, the choice of programming language gets hidden behind the EXPOSE command in a Dockerfile. Take for example this FORTRAN web framework; would you consider it for your next application?
https://fortran.io/

Programming languages explained with music pic.twitter.com/jrDCXXN9fT

— Elena Neira (@elenaneira) January 18, 2020

2. Do you remember when IBM finished the acquisition of Red Hat last year? Well, what was bound to happen has happened: OpenShift in mainframes! Not even Fred Brooks saw that one coming. This means that not only FORTRAN will become the next big thing in Kubernetes; PL/I and COBOL are next (something the organizers of the upcoming HOPL IV conference could rejoice about!) Speaking about ancient languages, how about returning Latin HTTP status codes from your app?
https://blog.openshift.com/ibm-and-red-hat-bring-openshift-to-ibm-z-and-linuxone/
3. Most modern programming languages store floating point values using the IEEE 754 standard format, first published in 1985. However common it might be, many developers still struggle to figure out how it works. This is why the float toy by Ewan Wallace is so useful.
http://evanw.github.io/float-toy/
4. Even though Rust is nowadays quite popular, many developers stick with more conservative, tested technologies, such as Python or Ruby. Or Python and Ruby. Or just plain Go, which remains a common choice for cloud native apps. If that’s your case, check this article about vanity import paths in Go by Márk Sági-Kazár. The users of your library will appreciate!
https://sagikazarmark.hu/blog/vanity-import-paths-in-go/
5. The tool of the week is Docker… written in 100 lines of Bash. Because, why not? After all you could use any Turing-complete language to do the job. We’re pretty sure the authors used this cheatsheet to help them write it.
https://github.com/p8952/bocker
Which programming languages do you use to create your cloud native apps? Have you ever deployed apps in IBM Z systems? 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.

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 are going to talk about different tools and techniques to declare and configure infrastructure as code.
1. CfgMgmtCamp Ghent 2020 just ended (how do you even pronounce the name?) so let’s talk configuration. As explained by Adrien Trouillaud, „There are two basic ways to deploy to Kubernetes: imperatively, with the many kubectl commands, or declaratively, by writing manifests and using kubectl apply.“ Of course in VSHN we’re great fans of infrastructure as code and GitOps, and our upcoming Project Syn is all about that.
https://medium.com/payscale-tech/imperative-vs-declarative-a-kubernetes-tutorial-4be66c5d8914
2. JSON or YAML? These days we need a bit more than that. Systems like Kustomize showed the way to extensible systems, where DRY is king. The latest contenders in the game are Jsonnet and jk. The latter allows us to write JavaScript templates, which can generate YAML or JSON as required. Another layer of abstraction, hopefully not a leaky one.
https://jkcfg.github.io/
3. In the same vein as jk, the Dhall configuration language proposes a mechanism to create a „single source of truth“ for all of our configuration needs.
https://dhall-lang.org/
4. If you work with Kubernetes (who doesn’t these days?) you will find KUDO and Tanka to be useful additions to your toolbelt. The former is a toolkit to build Kubernetes Operators using plain YAML, while the latter is composable configuration utility based on Jsonnet.
https://tanka.dev/
5. For those working with cloud providers such as Azure, Google Cloud, or AWS, you might want to try out Gyro and Checkov. Gyro abstracts all infrastructure with an ad-hoc configuration language, while Checkov provides ready-to-use best practices and policies to apply in major cloud environments. But whatever tool you use for your configuration, whatever your environment, remember:

Note to self: Don’t deploy on Fridays

— Twitter Engineering (@TwitterEng) February 7, 2020

https://gyro.dev/
How do you manage configuration changes? Do you use some of the tools described in this article? Do you have some others to recommend? 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.

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 are going to talk about the latest news about OpenShift, the enterprise-ready Kubernetes platform by Red Hat.
1. Red Hat released OpenShift 4.3 a few days ago. This new version of OpenShift brings lots of new features increasing the security of container deployments in the platform: FIPS 140-2 Level 1 compliant encryption, choice of cipher suites for the Ingress controller, new built-in data protection features in Red Hat OpenShift Container Storage 4, and the new Container Security Operator for Red Hat Quay. Lots of new features and relentless innovation. (Kubernetes 1.17 was also released recently, but we’ll talk about it in a future edition of VSHN.timer, since OpenShift 4.3 is based on K8s 1.16.)
https://blog.openshift.com/introducing-red-hat-openshift-4-3-to-enhance-kubernetes-security/
2. Migrating to OpenShift 4 is not as simple as running an installer. It requires planning, architecture, design, and strategy. That’s why Red Hat has put together a guide to help in the migration of clusters to the latest and greatest OpenShift using the Cluster Application Migration tool (CAM), a tool based on Velero and Restic.
https://blog.openshift.com/migrating-your-applications-to-openshift-4/
3. Of the more than 90 Kubernetes distributions certified by the Cloud Native Computing Foundation, Axa Schweiz chose OpenShift for their operations. Why? Axa Schweiz CIO Andy Maier explains it all in this article in the Inside Channels blog (in German).

For Maier, Openshift is a central element of the cloud strategy. „I would never put my applications natively on a cloud,“ he explains, adding that he must minimize the strategic dependency that also exists in the cloud. „If I have a problem with a cloud provider in three or four years, then I’ll have a problem of two to three million francs over a year and a half, not a 20 million franc problem that will take three to four years to solve.“

https://www.inside-channels.ch/de/post/am-meisten-respekt-haben-wir-vor-dem-mainframe-teil-20191212
4. Development teams who would like to run a small OpenShift 3.11 cluster previously relied in Minishift. Red Hat announced previously that Minishift will not be upgraded to OpenShift 4, instead offering CodeReady Containers (CRC) to fulfill this need. This product is officially only supported in some flavors of Linux (using KVM, not VirtualBox!) like Fedora, RHEL or CentOS, which left Ubuntu users on their own to find out the required dependencies. Thankfully Markus Hansmair of ConSol Labs wrote a fantastic article with all the information required to get started with CRC in one of the most popular Linux distributions out there.
https://labs.consol.de/devops/linux/2019/11/29/codeready-containers-on-ubuntu.html
5. The tool of the week… is actually a list thereof! Here’s the „Golden Kubernetes Tooling and Helpers list„, an incredibly exhaustive list of Kubernetes-related tools. We’re sure you will discover something new in it.
https://docs.google.com/spreadsheets/d/1WPHt0gsb7adVzY3eviMK2W8LejV0I5m_Zpc8tMzl_2w/htmlview
Are you using OpenShift clusters in production? Have you migrated to OpenShift 4? Are your development teams using CodeReady Containers already? 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.

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 are going to talk about the latest developments in cloud, DevOps, and network security.
1. As computers grow in power and speed, so do older algorithms become weak and insecure. This is unavoidable in our industry. The latest victim of this process was the SHA-1 cryptographic hash function. Published in 1993, and already considered potentially insecure since 2005, it has finally been broken down entirely. As the authors say: all common attacks on the MD5 message digest algorithm now work on SHA-1 as well. You’ve been warned.
https://sha-mbles.github.io/
2. Here at VSHN we’re strong supporters of Open Source, and we have shared lots of code with the community. We know the hard work it takes to release software, including good documentation, tests, keeping dependencies updated and supporting developers who contribute pull requests and raise issues. This collaboration represents, indeed, lots of happiness and lots of stress. But security has become a major issue lately in the Open Source community. Dan Lorenc from Google Cloud raises awareness in an excellent (if somewhat scary) article.
https://medium.com/better-programming/getting-serious-about-open-source-security-1d15609478fa
3. There’s never enough guidance to avoid security catastrophes. The SANS Institute has made freely available a massive poster called „Secure DevOps Toolchain and SWAT Checklist“ to print and pin to the walls of your organization. It includes a thorough checklist to secure web applications technologies, and lists of activities and checks to perform during development, deployment and maintenance. Couple this with some Docker Security 101 guidelines and you should sleep better at night. Oh, and don’t expose the .ssh folder in your web server. Just don’t.

4. And if all the security prevention measures weren’t enough after all… here’s Hannah Culver from Blameless teaching us 5 best practices for postmortems. We’re very sorry!
https://www.blameless.com/5-best-practices-nailing-postmortems/
5. The tool of the week is Kubernetes Secret Decode, a kubectl plugin to show Kubernetes secrets encoded with base64.
https://github.com/ashleyschuett/kubernetes-secret-decode
How do you manage the security of your cloud deployments? Do you have any other 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.

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 are going to talk about the various ways in which DevOps transforms hiring processes, and how it impacts organization culture.
1. We were not surprised to learn that DevOps skills are currently the hottest commodity in the IT HR market. Spoiler alert: here in Switzerland too! Our own DevOps survey shows that more than 90% of Swiss firms use DevOps practices of some kind. Speaking about which: did you know we are hiring?
https://www.zdnet.com/article/devops-now-most-sought-after-skill-survey-finds/
2. Organizations embracing DevOps practices experience fundamental changes. They bring together formerly separated skills and attitudes, maximizing the potential of teams with visible returns on investment. This newly found cooperation makes engineers learn about sales processes, to adopt excellent internal communication skills, and even to start designing APIs with customers in mind. All activities of an organization are impacted and integrated after investing in DevOps.
https://matthewrocklin.com/blog/work/2019/12/05/engineers-and-sales
3. Starting a new company is very hard. To help you build the next unicorn, Version One has published the Startup Handbook, a free e-book divided in three core areas: how to build your team, how build your organization, and how to find investors. Each item includes links to other books, articles and best practices. One interesting data item from this handbook: did you know that only 20% of candidates accept an offer? The IT HR market is a seller’s market and competition to get top talent is very tough.
https://versionone.vc/startup-handbook/
4. How diverse is your organization? If you work in IT, just look around you: your co-workers are mostly (by a large margin) white males between 25 and 35 years old. Hiring processes in our industry are biased, driven towards hiring people that are somewhat similar to the current employees. This „auto-pilot“ bias can be unlearnt and fixed. About three years ago, Atlassian shifted their focus in the hiring process, focusing on values instead of skills. Just like Atlassian, organizations all over the world are (finally!) figuring out that the human factor is the most important one for a successful DevOps transformation. (By the way: check out our VSHN Handbook to know more about our values.)
https://www.atlassian.com/blog/inside-atlassian/how-to-fix-brogrammer-culture-hire-for-values
5. Given the complexity of the DevOps technology landscape, it is very important that our colleagues have the basic technical skills for the job. So while you’re hunting for the people with the right values, the tool of the week is a simple list of five basic Kubernetes interview questions you might want to ask to your next candidate. But as the Harvard Business Review once said, hire for attitude, train for skills.
https://opensource.com/article/19/12/kubernetes-interview-questions
How diverse is your team? Have you reviewed your hiring processes lately? Have you adopted DevOps practices in your organization? 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.

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 are going to talk about the many aspects and traps of Cloud-Native Architectures.
1. Remember when Microservices where the new silver bullet? Thankfully the industry has matured now, collecting and documenting tons of best practices, including pattern languages and interesting recommendations on when to use microservices (or not!) Christian Posta recently discussed how Istio is transitioning its control plane to a monolithic architecture, and states this gem:

“It’s okay” to go back to a monolith if your assumptions or the context around your decisions have changed.

https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/
2. The nxt engineering team has recently published a detailed step-by-step tutorial about how to build and deploy Quarkus applications on APPUiO, our Swiss-based container platform. Quarkus is a microservices-oriented implementation of the Java Virtual Machine, and is credited with bringing Java back to the epicenter of cloud-native applications. The article guides the reader from the development phase to deployment and scaling, and the source code is available online. Check it out!
https://nxt.engineering/en/blog/quarkus_appuio/

2014 – We must adopt #microservices to solve all problems with monoliths
2016 – We must adopt #docker to solve all problems with microservices
2018 – We must adopt #kubernetes to solve all problems with docker pic.twitter.com/CrnvX9Lgpq

— Syed Aqueel Haider (@sahrizv) July 14, 2018

3. Metcalfe’s Law states that the value of networks grow proportionally to the square of the number of nodes. Is the probability of failure in microservices architectures proportional to the square of the number of services? The subjective perception of an unlucky sysadmin might suggest an exponential catastrophe instead. In any case, you should prepare for the worst, and Daniel Sada Caraveo has prepared a nice list of practical tips and tools to use in order to sleep better at night after a deployment: logging, monitoring, load balancing… Couple this with some Service Level Objectives (SLOs) and error budgets and you could achieve some unprecedented peace of mind.
https://danielsada.tech/blog/cloud-services-dos/
4. Regular readers of the VSHN.timer series know that we are particularly fond of Kubernetes. We have seen, however, that many developers struggle to understand how it works or how it’s built. The nice people at KodeKloud have published a fantastic 10-minute video explaining the architecture of Kubernetes in great detail. A fantastic learning resource for newcomers to the cloud-native world!
https://www.youtube.com/watch?v=8C_SCDbUJTg

5. The tool of the week is Terrastruct, an online diagramming tool that might help you bring those architectures and microservice API patterns to life.
https://terrastruct.com/
Have you migrated your monolith to a microservices architecture? Which best practices have worked the best for you? 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.

Happy 2020 and welcome to the first VSHN.timer of the year! 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 are going to start this new year by reflecting on how quickly (and weirdly) technology evolves.
1. Did you know that the RIPE NCC ran out of IPv4 addresses on November 25th, 2019? There used to be a time when companies like Apple (17.0.0.0/8), Ford (19.0.0.0/8), and even Merck (Ford? Merck?) got a full Class A block with 16 million IPv4 addresses each. That’s without counting with the USA Department of Defense, who owns 200 million IPv4 addresses alone. To the point that Ars Technica asked in 2011 whether there should be a free market for those. Would the price of a single IPv4 address have exploded if the IPv6 standard did not exist?
https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/the-ripe-ncc-has-run-out-of-ipv4-addresses
2. Did you know that the Linux kernel dropped support for floppy drives in July 18th, 2019? For the youngest among you reading these lines, floppy drives were the equivalent of USB drives back in the day, but with way, waaaaaaay less capacity. Like, a lot less. They did not even have enough space for a single MP3 file. But you could play music with them anyway. I bet you can’t use USB drives like that. Nostalgic much? No worries. Just install Windows 95 in your Android phone or in your laptop. It’ll bring back nice memories for sure.
https://www.zdnet.com/google-amp/article/linus-torvalds-prepares-to-wave-goodbye-to-linux-floppy-drives/
3. Did you know that the only true constant in the Internet are heated discussions? Take for example this recent Python Enhancement Proposal (PEP) asking „to impose a limit of one million on various aspects of Python programs, such as the lines of code per module.“ Other items that would be limited to one million would be the number of bytecode instructions in a code object, and the number of live coroutines in a running interpreter. All in all, 7 restrictions. Hang tight before clicking on this one.
https://lwn.net/Articles/807218/
4. Did you know that you are not Google? Neither are we, neither is anyone–well, except Google. Yet most software developers and architects and entrepreneurs and consultants seem to forget it. So we thought we’d better remind you. Because the US Air Force did not know it, and then deployed a Kubernetes cluster in an F-16. Maybe they misunderstood what „cyberwarfare“ means, and plan to shoot down enemy aircraft with Docker containers? Well, that’s literally what they plan to do. Nobody saw this one coming.
https://thenewstack.io/how-the-u-s-air-force-deployed-kubernetes-and-istio-on-an-f-16-in-45-days/
5. Did you know that the Agile Manifesto is almost 20 years old? One may argue that DevOps is the logical continuation, the „cloud-first“ evolution of the Agile world. Still, the body of knowledge and practices built during the first two decades of this century have shaken our industry in unfathomable ways. Maybe it would be time to revisit some of the core ideas? Take, for example, „story points.“ Ron Jeffries, the inventor of the concept, says that it might be time to sit down and rethink the concept of story points. What do you think?
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
How have you started the new year? Do you have any funny links for us to read? 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.

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 are going to finish this amazing 2019 with the latest news about Kubernetes.
1. Here at VSHN we are crazy about learning; remember our two recent VSHN.timer issues dedicated to the subject of learning? They were numbers 16 and 21. But we just can’t get enough! So for this edition, here go a few interesting links to learn more about Kubernetes: Kubernetes by Example, by the OpenShift team; an illustrated guide to Kubernetes networking; a checklist of Kubernetes production best practices; a visual guide to troubleshoot Kubernetes deployments; and how to export Kubernetes events for alerting! At this pace we should be releasing a VSHN.timer issue every day. Can’t keep up! (Oh and by the way, did we mention that Kubernetes 1.17 is out?)
http://kubernetesbyexample.com/
2. Kubernetes might have started as a single product, but it has now become a large family of software packages, collectively known as Kubernetes „distributions,“ somewhat akin to Linux distributions. These distributions can be certified for conformance, and there are literally a hundred of them! Some of them are small enough as to run in your laptop, while others are huge commercial offerings with great added value, such as OpenShift, NetApp Kubernetes Service, or Rancher. But how does this Kubernetes distribution thing work? How do you create one, and does certification matter? This recent article in LWN.net explains how it all works, why there isn’t a community-driven distribution, and why it matters.
https://lwn.net/Articles/806230/
3. The Alibaba Cloud Container Service for Kubernetes (ACK) is one of the fastest growing Kubernetes services; we’ve even heard about some Swiss companies who are running deployments in it now! This article in the Cloud Native Foundation blog explains how they run, scale and manage thousands of clusters. Great insight into the operations of a large cloud provider.
https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/
4. What about our „fear of missing out“? With all these news, about Kubernetes this and Kubernetes that, it is hard not to feel the FOMA flow through our veins. The kind folks at Sysadvent reminded us recently that it is OK not to use Kubernetes. Jumping to the latest and greatest technology involves much more than just typing kubectl commands, and not all teams are prepared to handle the risk. Better yet, find the technology that works best for you and create great products with it! But of course, if you’re feeling adventurous, there’s another Sysadvent article about migrating a Rails app to Kubernetes.
https://sysadvent.blogspot.com/2019/12/day-10-it-ok-if-you-not-running.html
5. The tool of the week is kubectl doctor, a plugin for kubectl to scan your clusters to find any anomalies, reporting back useful action points in YAML format. Must have!
https://github.com/emirozer/kubectl-doctor
Do you run Kubernetes in production? If not, would you like to? How do you learn about cloud technologies? Get in touch with us through the form at the bottom of this page!
PS: Dear readers, we’re going to take a small break in VSHN.timer; see you in January 6th for the first edition of 2020! The VSHN.timer team sends you our best season’s greetings and thank you for your fidelity.