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 Cloud Security, its many facets and threats, and how smart teams can mitigate them.
1. Last October Google announced new features to control the security of applications deployed in the Google Kubernetes Engine (GKE). First, application-layer Secrets encryption, to protect Kubernetes Secrets with envelope encryption. Second, customer-managed encryption keys (CMEK) for the encryption of GKE persistent disks. Following the recent availability of a Zurich region of Google Cloud (just like Azure does) and the recent concerns in Switzerland about the use of USA-based cloud services, this clearly will be of interest for the local market.
https://cloud.google.com/blog/products/containers-kubernetes/exploring-container-security-use-your-own-keys-to-protect-your-data-on-gke
2. Encryption is only a small part of a security strategy. And keys, as useful as they are, require management, storage, distribution, and lots of attention. Cloudflare recently reminded us that public keys are not enough for SSH security, and that we should we using Cloudflare Access instead, replacing SSH keys with short-lived certificates.
https://blog.cloudflare.com/public-keys-are-not-enough-for-ssh-security/
3. Two recent security-related research papers have caught our attention. First, this presentation in the 27th Usenix Security Symposium (2018) about attacking certificate authorities with Border Gateway Protocol (BGP). And second, this presentation about BPFs (Berkeley Packet Filters) touted as a „new type of software,“ and which might as well become a „next frontier“ in security. BPFs are a radical change in the venerable, 40 year-old Unix operating system architecture, opening new possibilities, for example in the field of attack monitoring and prevention.
http://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html
4. Security is hard. Atlassian (re-)discovered this as the SwiftOnSecurity Twitter account inadvertently disclosed a security vulnerability in Confluence last week. Atlassian provided a domain that resolved to a local server with a common SSL certificate for its Confluence cloud service, but anyone could copy that key and use it for a man-in-the-middle attack, allowing an attacker to redirect traffic to a malicious site.
https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/
5. Finally, the tool of the week is Octarine. Going beyond container scanning, Octarine offers threat detection and blocking, and app segmentation scaling, using a sidecar model that allows for compliance checks and automation of security tasks.
https://www.octarinesec.com/
How do you manage the security of your cloud infrastructure? Have you developed and open sourced any security-related tools? 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 showcase some cool examples of excellent learning resources created by and for the DevOps community.
1. Julia Evans, software developer and zine author in Montreal, has been producing excellent and instructive comic magazines for many years, explaining the inner working of different technologies. Among those, she recently explained how Docker containers work with overlayfs in her unique style, and we simply loved it. She has a whole section in her website about Containers and Kubernetes with great content!
https://jvns.ca/blog/2019/11/18/how-containers-work–overlayfs/
2. Learning technologies with pictures and drawings is not new; remember the Head First book series by O’Reilly? It certainly redefined the way computer books were produced and designed. Following the same idea, Sudhakar Rayavaram published a fantastic article in Medium explaining Kubernetes in pictures! Ever felt the need to explain how K8s work? Well now you know.
https://medium.com/tarkalabs/know-kubernetes-pictorially-f6e6a0052dd0
3. We are in December again: time for sysadvent 2019! From the 1st to the 25th of December, every day a new article about the subject, since 2008. This year’s series started with an article about alerting with Prometheus.
https://sysadvent.blogspot.com/2019/12/day-1-alerting-with-prometheus.html
4. The four types of technical documentation are Tutorials, How-to Guides, Discussions, and Reference. In the case of How-to Guides, we think Flowshare has the potential of becoming a very interesting resource in the future.
https://flowshare.io/
5. The tool of the week is kubethanos, whose task consists in killing „half of your pods randomly to engineer chaos in your preferred environment.“ A useful tool to test the solidity of our clusters, and we think it has the best name ever!
https://github.com/berkay-dincer/kubethanos
Do you know any other cool learning resources? What books or podcasts have you discovered lately? 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.
Last week was full of conferences, new product announcements, and exciting news! There was ServiceMeshCon, then KubeCon / CloudNativeCon, and even MulticloudCon. This VSHN.timer will feature what we think are the five most prominent news of the week.
1. VMWare announced Project Antrea, a „Kubernetes networking solution intended to be Kubernetes native. It operates at Layer 3/4 to provide networking and security services for a Kubernetes cluster, leveraging Open vSwitch as the networking data plane.“ They also showcased Octant extensively during the week, „an open source developer-centric web interface for Kubernetes that lets you inspect a Kubernetes cluster and its applications.“
https://github.com/vmware-tanzu/antrea/
2. Buoyant, the team behind linkerd, announced the release of the private beta of Dive, a „SaaS team control plane for platform teams operating Kubernetes“ (not to be mixed up with the Docker container explorer of the same name!)
https://dive.co/
3. Rancher made two important announcements last week: first, Rio, a new application deployment engine for Kubernetes that takes „technologies such as Kubernetes, knative, linkerd, cert-manager, buildkit and gloo and combines them to present a holistic application deployment environment.“ And second, K3s version 1.0, the „certified Kubernetes distribution built for IoT & Edge computing.“
https://rio.io/
4. Red Hat announced OpenShift Hive, an OpenShift operator which „enables operations teams to easily provision new PaaS environments for developers improving productivity and reducing process burden due to internal IT regulations.“
https://blog.openshift.com/openshift-hive-cluster-as-a-service/
5. If you can’t get enough from conferences, check out all videos from KubeCon / CloudNativeCon already available on YouTube! You might want to get some popcorn (or order some pizza and drinks) before hitting the play button… there are 320 videos, a whole week of back-to-back playback! Don’t know where to start? Then watch Bryan Liles‚ excellent keynote: „In Search of the Kubernetes ‚Rails‘ Moment.“
https://www.youtube.com/playlist?list=PLj6h78yzYM2NDs-iu8WU5fMxINxHXlien

Did you attend any of these conferences? Have we missed some important announcement? 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 this exceptional edition with 7 items we are going to talk about managing „classic“ virtual machines with Kubernetes, a subject suggested by VSHNeer João Pinto; then we’ll dive into Helm 3.0 and into a deluge of conferences!
1. Some applications require a bit more than just plain containerization. Sometimes their developers only support them on fully-fledged virtual machines, or they require a higher level of isolation, because of security or performance concerns. So it is great news to see KubeVirt being promoted to a CNCF Sandbox Project!  By the way, Nigel Poulton talks about it as well in the last episode of the „Kubernetes This Month“ podcast, which you should check out every month anyway.
https://kubevirt.io/
2. Mention virtual machines and the name VMware comes up immediately. At the last VMworld in San Francisco, they announced VMware Project Pacific, a project specifically designed to support running VM-based workloads in Kubernetes clusters. This announcement (also covered by Nigel Poulton in September) means more and more IT teams can start integrating Kubernetes and containers into their more „classic“ environments, based on virtual machines.
https://www.vmware.com/products/vsphere/projectpacific.html
3. More players are jumping into this space lately. Mirantis open sourced their own VM-in-Kubernetes solution, called virtlet. One of the major goals of this project is to make VMs seamlessly integrate into Kubernetes pods, just like any other container, including networking, with a very straightforward integration.
https://github.com/Mirantis/virtlet
4. The distance between containers and virtual machines keep shortening, as Weaveworks has released Firekube, a Kubernetes cluster working on top of Ignite and AWS Firecracker. In a world of FaaS and microservices, expanding the options for running code fast and efficiently is a must.
https://github.com/weaveworks/wks-quickstart-firekube
5. Back to „traditional Kubernetes“ news, our dear container orchestrator continues its inexorable growth, in spite of the concern of some teams. Upcoming features such as „classic“ VM support and sidecar containers will further enhance this dominant position, with ever growing innovation levels all around its ecosystem. Speaking about which, one of the greatest news of last week was the release of Helm 3.0! A major (and much awaited) milestone for the official „package manager“ for Kubernetes. And yes, you read it right: Tiller is gone!
https://github.com/helm/helm/releases/tag/v3.0.0
6. The tool of the week is the kubectl-plugins project by Marko Lukša, engineer at Red Hat and book author. We simply loved the kubectl really get all command, which returns absolutely everything inside a Kubernetes namespace!
https://github.com/luksa/kubectl-plugins
7. And a bonus item this week, because conferences! Tonight starts ServiceMeshCon, tomorrow start KubeCon and CloudNativeCon! (there’s a livestream for the latter you might want to tune in tomorrow evening – CET time of course) and if all that wasn’t enough, there is also MulticloudCon in San Diego tonight! Stay tuned for the deluge of information during the week. We’ll have lots to say about them next Monday for sure!
https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/livestream/
Are you already running virtual machines in your Kubernetes clusters? Do you think this approach will become the next standard? Are you in the bay area attending ServiceMeshCon, KubeCon, CloudNativeCon, or MulticloudCon? Would you like to share your experience 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.
In this edition we are going to talk about languages, tools, and good ideas to write quality code.
1. Go is without a doubt the language of the moment. It enjoys an unprecedented level of popularity among cloud-first developers, and for some it might even be the new Ruby. Not only Docker, Kubernetes, OpenShift, and many other cloud-native tools are written in Go, but we have discovered a few more recently: vegeta the load testing tool, yar the security scanner, and even kubeprompt the Kubernetes-enabled command line prompt. Even Jaeger, the distributed tracing platform recently graduated as the seventh official CNCF project, is written in Go!
https://00f.net/2019/10/28/go-is-the-new-ruby/
2. In spite of the incredible traction of Go, our beloved Python remains a favorite language among VSHNeers. It is then with a certain nostalgia that we learnt the retirement of the creator of Python himself, Guido van Rossum, from the Dropbox blog. We wish him a great time and we thank him for such a great programming language! By the way, speaking about Python, we have been playing recently with FastAPI and it’s awesome.
https://blog.dropbox.com/topics/company/thank-you–guido

It's bittersweet: I'm leaving @dropbox, and am now retired. I've learned a lot during my time as an engineer here — e.g. type annotations came from this experience — and I'll miss working here. https://t.co/0ROaUrHQLt

— Guido van Rossum (@gvanrossum) October 30, 2019

3. But no matter which language you use, there is a 99,999999% chance that you are going to use Git to version your code and to collaborate with your peers. Some even say that Git is arguably Linus Torvalds‘ most important creation. Git is so pervasive in our industry that „DevOps“ sometimes is spelled „GitOps.“ In any case, we have learned through the Github blog that Git 2.24 is available, and there are quite a few changes to pay attention to. But undoing changes is still complicated in Git, to the point where we have to use decision trees to do it properly.
https://github.blog/2019-11-03-highlights-from-git-2-24/
4. And how do we write code? In 2019, it is increasingly through Visual Studio Code – or its MIT-licensed, analytics-free alternative, VSCodium. Here at VSHN we use it for nearly everything, from writing Go or Python code, PlantUML or Markdown documentation, to managing Docker containers or Kubernetes clusters, and even reading Excel spreadsheets! And even the AsciiDoc plugin author, João, is a VSHNeer now! Last week Microsoft held the Ignite conference, where they announced Visual Studio Online, a web-based, cloud-first version of Visual Studio Code. However, we at VSHN are more interested in how Microsoft grooms and triages issues in the project, an example of leadership and organization.
https://venturebeat.com/2019/11/04/microsoft-launches-visual-studio-online-public-preview-and-ml-net-1-4/
5. And speaking of a Microsoft that is still surprising us since Satya Nadella took office in 2014, here’s a few more gems from the Ignite conference last week: after the announcements of Azure Arc, a hybrid cloud, and Azure Quantum, a quantum-computing cloud, came the announcement of a 4-day workweek (or is it a 3-day weekend?) in Microsoft Japan. A company faithful to its roots, yet moving into the future; their first product was a developer tool, after all. Just in case, remember to check all boxes before deploying to Azure.
https://mspoweruser.com/microsoft-4-day-workweek/
Are you writing and deploying Go or Python code with Visual Studio Code? Or are you a vim enthusiast? Do you GitOps? Would you like to share other tools 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.

In this edition we are going to talk about building containers without falling in the root trap! This subject has been suggested by VSHNeer João Pinto, based on his research on the topic.

1. Let’s talk about the elephant in the room: the official Docker daemon currently requires root privileges. This causes a myriad of issues that block DevOps teams from reaching full potential and speed, including (but not limited to) the already complicated configuration of CI/CD pipelines. How can we solve this problem? It turns out that there is no need to run the container building process as sudo. We should be able to build containers without higher security privileges. Rootless Containers (home of the Usernetes project) has been tracking solutions to this problem since 2017, and contains a great recent presentation about the subject, embedded below for reference.

https://rootlesscontaine.rs/

2. Since the Rootless Containers website started, Bazel, Kaniko, BuildKit, Buildah and Podman appeared in the scene. Daniel J. Walsh from Red Hat wrote a great introduction to Buildah and another for Podman. As explained in the Buildah Github repository, both Podman and Buildah have different, yet complementary, functions:

https://opensource.com/article/19/3/tips-tricks-rootless-buildah

Buildah’s commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. (…)
Podman specializes in all of the commands and functions that help you to maintain and modify OCI images (…) For building container images via Dockerfiles, Podman uses Buildah’s golang API and can be installed independently from Buildah.

3. One of the nice features of Podman is that it can be integrated with Ansible, thanks to ansible-bender. This article by Tomas Tomecek from Red Hat shows exactly how, but beware: some operations actually require root access. We’re not totally over our addiction to sudo, it seems.

https://opensource.com/article/19/10/building-container-images-ansible

4. But maybe we need to develop a new kind of container technology? This is what Nabla containers is all about: „a new approach to container isolation.“ Nabla containers only allow seven specific systems calls to the Linux host kernel (read, write, exit_group, clock_gettime, ppoll, pwrite64, and pread64) while actively blocking all others, reducing the attack surface of compromised containers. For all other system calls, Nabla containers use „unikernel“ techniques, in this case specifically the Solo5 environment. Incredible research!

https://nabla-containers.github.io/

5. The tool of the week is makisu, a „fast and flexible Docker image build tool designed for unprivileged containerized environments such as Mesos or Kubernetes.“ Dockerfile-compatible and still under heavy development, the current version at the time of this writing is 0.1.12. This project is dragging lots of interest from the cloud-native app industry and we’re watching it closely.

https://github.com/uber/makisu

Are you building your containers with any of these tools? Or are you still using good old docker build? Do you know of any other similar tools 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.
In this edition we are going to talk about how to learn and to get started with Kubernetes, the standard platform for cloud-native applications.
1. There’s no better way to learn a technology than by using it, playing with it, and creating new things on top of it. Kubernetes isn’t the exception, and there’s a myriad of different services available online to help you get started with it. To name a few, there’s „Kubernetes Deep Dive“ by A Cloud Guru,  „Introduction to Kubernetes“ by the Cloud Native Computing Foundation, and „Learn Kubernetes by Doing“ by Linux Academy. But today we’d like to highlight Learnk8s, a service with an unmistakable name: Kubernetes training for beginners and advanced developers, both online and on-site; all in bundles of e-books and videos. It might exactly be what your team needs to get started!
https://learnk8s.io/

Why @kubernetesio? From the creator of https://t.co/ATmFlfLZnV @try_except_ pic.twitter.com/SdqBUHlb1X

— Alex Ellis (@alexellisuk) October 24, 2019

2. Once you’ve learnt the basics, you might want to deploy apps in your own cluster. The easiest starting point is of course running a small cluster in your laptop, but how about a bigger, more challenging project? Chris Bensen wrote a 5-part series on how to build a Kubernetes cluster with Raspberry Pi machines. Here are the links to part 1, part 2, part 3, part 4, part 5, and part 6 of the series. The articles cover all the required steps, from the hardware setup to the software architecture. A fun weekend project!
http://chrisbensen.blogspot.com/2019/06/very-large-raspberry-pi-cluster-part-i.html
3. The meat and bread of Kubernetes is the descriptive approach of resources; YAML manifests (conveniently stored in a Git repository) describe the state of the system, and Kubernetes makes sure that the running cluster matches the manifests at all times. One of the first challenges new developers face with Kubernetes is, precisely, getting those manifests right. Matty from Prefetch Technologies wrote a short beginners guide to Kubernetes manifests, with all the information you need to start writing manifests in no time.
https://prefetch.net/blog/2019/10/16/the-beginners-guide-to-creating-kubernetes-manifests/
4. Writing YAML correctly is just the beginning of your Kubernetes journey. Very shortly you’ll be writing more and more manifests, dealing with persistent volume claims, secrets, `ConfigMap`, services, deployments, Ingress, storage classes, `StatefulSet`, network policies, RBAC, admission controls, autoscaling… and then you’ll realize that treating your clusters as cattle instead of pets is the right approach (and also, that sometimes things go terribly wrong). Kubernetes architecture patterns start to emerge; Microsoft and Alibaba have teamed up to create the Open Application Model, a standard specification for cloud-native apps, going beyond the 12 factor app. Microsoft published Rudr, a Kubernetes-based sample implementation of OAM freely available; but what does this all mean for app developers? Janakiram MSV wrote an article in The New Stack that provides some light on the implications of Rudr in the future of Kubernetes.
https://thenewstack.io/what-does-the-open-application-model-oam-and-rudr-mean-for-kubernetes-developers/
5. The tool of the week is a cool cross-platform command line tool (written in Go, of course!) to manage your clusters: K9s. It will help developers new to Kubernetes to manage their clusters using a straightforward, uncluttered visual tool. But before you continue working on that terminal window, remember to install a nice fixed-width font like Hack. Your eyes will thank you for that.
https://k9ss.io/
How did you get started with Kubernetes? Did you read any books on the subject? Do you know of any great learning resource 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.
In this edition we are going to talk about ideas, tools, and approaches that make (or break) early 21st century startups.
1. One of the founders of sociology, German sociologist Max Weber, published a series of groundbreaking works about leadership, management, and authority. It was one of the first attempts to explain the nature of social organizations, with a deep impact in social sciences. One of the core tenets of Weber’s work was his antipositivism, that is, the need to go beyond and above the scientific method to describe human relationships, through empathy and mutual understanding. Fast forward a hundred years after Weber’s death, the topic of management of software startups is slowly reverting to Weber’s views, after decades of Taylorism and positivism. Alex Ellis, the founder of OpenFaaS, recently published a fantastic article about the five pressures of leadership in the world of Open Source, DevOps, and remote work. His thesis evolves around the concepts of empathy, kindness, understanding, and communication. A new paradigm based on good old ideas, and a required reading for our frantic times.
https://blog.alexellis.io/the-5-pressures-of-leadership/
2. For decades, technical companies argued that their work was strictly non-political, devoid of partisanship, and strictly neutral. But the reality is quite different. Technology startups are redefining and „disrupting“ not only markets, media, and business, but also politics, economy, and society at large. Case in point: GitLab had to reverse its decision to allow for unethical business under pressure from its employees and the broader community of users. In the era of social media empires undermining democracies, supporting repressive governments, and openly dismissing human rights, society calls for transparency, ethics, collaboration, and consensus. Maybe we need to adopt some of the core DevOps ideas to rebuild our democracies?
https://www.theregister.co.uk/2019/10/17/gitlab_reverse_ferret/
3. Software startups are caught in a basic conundrum; you need to deliver features as quickly as possible, yet doing so can dramatically increase your technical debt. Hence, „architecture,“ the dreaded word, comes in as a mechanism to bring order into chaos. Does this always work? Not really. Big corporations end up with „architectural teams“ overseeing projects, dictating instead of counseling, writing hundreds of pages of documentation that nobody reads, and slowing down the delivery process altogether. To prevent teams from ending up in such a grim situation, Gergely Orosz wrote an article detailing his experience in the Uber and Skype teams. Those (very large!) teams created their architectures following an organic approach, through discussion, feedback loops and mutual understanding. The result? No buzzwords, no UML diagrams, but working, documented, and maintainable, code. A simple approach for simpler architectures, perfect for these times of boring one person companies.
https://blog.pragmaticengineer.com/software-architecture-is-overrated/
4. Speaking about communication, how can modern, distributed teams collaborate effectively to achieve empathy, disruption, and ethics? How can you leverage the tremendous amount of talent available overseas and build a distributed startup? This is by far the greatest challenge of our generation. Amir Salihefendic, founder and CEO of Doist, provides some absolutely ground-breaking advice in his article Asynchronous Communication: The Real Reason Remote Workers Are More Productive. The key for success, according to Amir, is the „asynchronous“ part, and how to balance that with synchronous meetings. This can have a very strong impact in the culture of teams, and the article provides a wealth of information. Absolutely must read for anyone working in a distributed team.
https://doist.com/blog/asynchronous-communication/
5. Instead of a tool, this week we will recommend an upcoming book: The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim. This book is a sequel to The Phoenix Project, a novel about DevOps published in 2018, which quickly became a global sensation, and a beacon marking a new era in software delivery. This eagerly awaited new book is already making a lot of buzz, and we have already pre-ordered our copy!
https://www.amazon.de/gp/product/1942788762/
What other ideas help your team work better? Is your startup spread all around the world? Do you have any best practices 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.
In this edition we are going to review the latest Kubernetes news, tools, and events. Hang tight, for the world of Kubernetes is advancing fast, fast, FAST! It is hard to keep up, even when watching an excellent podcast such as Kubernetes This Month. So here is our contribution, providing some signal out of all the noise.
1. Kubernetes is the current de-facto standard for cloud applications; all emerging trends in cloud technologies directly concern Kubernetes. It is then with joy that we observe the industry sharing and applying best practices around it. Let’s be honest: the most simple scenarios can still baffle many developers new to the platform: what is the best way to deploy apps in K8s? Kustomize? Helm? Individual YAML files? WKSctl? Using a UI such as those provided OpenShift 4, Rancher 2.3, or NetApp’s Kubernetes Service ? To provide an answer, this article by Colin Walker provides a great introduction to Helm when deploying apps to K8s. The author dives into Helm charts, secret management, and many other subjects. Must read.
https://itnext.io/best-practices-for-deploying-to-kubernetes-using-helm-73be1f3040d2
2. Developers new to Kubernetes must face a swath of new keywords, terminology, and buzzwords. Among those, Load Balancers, Liveness Probes, and of course, Controllers. What are Kubernetes Controllers? How do they work? How do they relate to Operators? To get answers to those questions, check out these slides by Kenta Iso. They include a simple yet effective overview of Controllers, their raison-d’être, internal structure and major characteristics. A great resource!
https://speakerdeck.com/govargo/inside-of-kubernetes-controller
3. Another common concept in the world of K8s is that of proxies. They play a critical role in any production-scale cloud native app. The standard choices these days are Envoy Proxy, HAProxy, and nginx. But which one to choose? This article by the Ambassador team provides a fantastic benchmark of those, with hard data, the information to reproduce the tests, and excellent results. Make sure to check this before you choose your proxy software.
https://www.getambassador.io/resources/envoyproxy-performance-on-k8s/
4. After all the technical considerations, let us not forget about costs. Cloud technologies can easily shrink the IT budget of an organization if left unchecked (serverless gone wild, anyone?) How to properly deal with costs when apps are deployed through Kubernetes? Tools like the AWS Cost Explorer can certainly help, but can we setup limits at the K8s level directly? Developers can set quotas, which vary from one technology stack to another. But they can also set resource requests and limits at container level, to  control their costs while at the same time ensuring appropriate performance levels. This article in the Kubecost blog provides a great introduction to resource requests and limits.
http://blog.kubecost.com/blog/requests-and-limits/
5. The tool of the week is Kontena Lens, a cross-platform desktop application (compatible with Linux, macOS and Windows) providing developers with a convenient point-and-click interface to manage clusters conveniently. For the moment, the application is in heavy development, and it is available for free, although an invitation is required to use it. Very useful!
https://www.kontena.io/
What other Kubernetes tools would you recommend? Are you deploying apps in Kubernetes? Do you have any best practices 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.
In this edition we are going to talk about ethics, remote teams, writing skills, and career development in a modern, distributed DevOps team.
1. In a world almost entirely run by software, (to the point where software greets other software, see the tweet quoted below), engineers are the ones shaping the future with every system we put in production. The prime principle in Ethics, „Primum non Nocere“ should be the one guiding our choices, helping us face trade-offs with open eyes through conscious choices. In this sense, this recent article by Andrew Marantz at the New Yorker is an eye opener. Internet is the new printing press, the tool shaping mankind in ways never before seen. We know we can endlessly disrupt markets and ideas thanks to the wonderful Von Neumann architecture; the question we should be asking is rather, should we?
https://www.newyorker.com/magazine/2019/09/30/the-dark-side-of-techno-utopianism

So this just happened:

– a bot found a vulnerability in a dependency
– a bot sent a PR to fix it
– the CI verified the PR
– a bot merged it
– a bot celebrated the merge with a GIFhttps://t.co/mHnWudZlUs pic.twitter.com/kNEPY5RSHr

— Gabriele Petronella (@gabro27) September 16, 2019

2. Working remotely is the next major paradigm shift in the information economy; one that will shake the foundations of work, leisure, trade, and productivity. Most DevOps teams already work remotely to a certain degree (home office, anyone?) thanks to a wise combination of tools such as Git, wikis, issue trackers, and cost-effective video communication systems. Skype, Google Hangouts, and Zoom come to mind, but are certainly not alone in the market. The problem, as always, is not technical; it is human. How do great teams communicate when they are not in the same location? What are the best practices that make effective remote meetings work better? This article by Chelsea Troy explains how the caucus problem makes remote meetings suck, and how to solve it with a meeting moderator. An enlightening read. And if you are a manager dealing with remote teams, LeeAnn Renninger has 11 questions to regularly ask your remote employees.
https://chelseatroy.com/2018/04/05/how-do-we-make-remote-meetings-not-suck/
3. In the ever-changing world of geographically dispersed DevOps teams, writing is a fundamental, yet vastly underrated, skill. Teams who collaborate through writing are stronger and more resilient. We at VSHN we write down everything all the time! Tickets and wiki pages, documentation websites and README files are there to help us work better together. The idea is not new: RFCs work exactly like that! This is why this article by Gergely Orosz is so important. Re-learning to write is required, and we need more of it. Joel Spolsky said it 19 years ago: „Writing is a muscle. The more you write, the more you’ll be able to write.“ Get your copy of Zinsser’s On Writing Well and read it. You will thank us.
https://blog.pragmaticengineer.com/on-writing-well/
4. We have seen that the modern software world requires knowledge of ethics, social interaction, and writing skills. But do universities teach those skills? The truth is that most Computer Science departments focus on technical matters–and rightly so, for software is complex. But these days we need to shift the focus back to the so-called „social sciences.“ David Deming, from the College of Arts and Sciences of Indiana State University, argues that there is a long-term benefit in liberal arts majors, compared to the short-term gains of STEM majors. Being able to evaluate the impact of our technical choices is a factor of incredible importance in our world today. We need to teach software skills to liberal arts majors, just as we need to teach social sciences to software engineers.
https://www.indstate.edu/cas/library/2019/09/engineers-sprint-ahead-don’t-underestimate-poets
5. And since working in a team means sharing secrets such as passwords, keys, and tokens, here is gopass: a tool based on Go and Git ready to help your team. It is compatible with pass, the standard Unix password manager, so it integrates nicely with existing mobile apps and browser plugins. The development team did not just port pass to Go, but actually enhanced several aspects of the original design. Moreover, they even wrote a document highlighting some security caveats to consider when using the tool. A nice addition to any team toolbox.
https://www.gopass.pw/
Does your organization work remotely? Do you write down specs, events, and documentation for the future? Do you have any best practices 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.

In this edition we are going to talk about container runtimes, the basic building blocks enabling everything we do every day at VSHN.

1. These days there is no need to introduce Docker anymore. When it appeared in 2013 it triggered a durable change in the way server applications are developed and deployed. But we are living in 2019, not in 1995 anymore, and the industry these days expects open standards to grow and evolve. That is why Docker, together with other vendors such as Google, created the Open Container Initiative, while at the same time opening up the code of runc, one of the the lower layers of Docker. After its introduction, runc became the reference implementation of container runtimes of the OCI runtime specification.

https://www.opencontainers.org/

2. But where do containers come from, anyway? They are a modern evolution and a combination of several Linux technologies, namely Linux namespaces and cgroups. The former abstracts system resources, like the file system, while the latter provides limits to the consumption of CPU and memory. But to understand more their nature and function, Ian Lewis from Google wrote a series of four articles that describe their inner soul: part 1, part 2, part 3 and part 4. Simple, short and fantastic explanations to understand the core technology making cloud native apps possible.

https://www.ianlewis.org/

3. These days there are many other container runtimes popping up. Just to name a few: Podman, Canonical’s LXD, and CoreOS‘ rkt. And one can expect many more in the future for sure, given the fierce competition in this space.

https://coreos.com/rkt/

4. Containers became so pervasive that they begat a whole new category of software systems: „container orchestration systems„, a family in which Kubernetes finally became the dominant option. After a short war with Docker Swarm and Apache Mesos, that is. The weight of Kubernetes (and Google) was such that, in order to open it to other runtimes (at the beginning it only supported Docker) the project published its Container Runtime Interface (CRI). The Cloud Native Computing Foundation established containerd, a reference implementation for container runtimes, „with an emphasis on simplicity, robustness and portability„, as one of the first CRI-compatible runtimes. Some examples of Kubernetes-ready container runtimes include of course Docker and containerd, but also cri-o and frakti.

https://containerd.io/

5. We clearly cannot get enough of container runtimes. Want to build yours? Of course you can! Liz Rice shows you how to write one in 100 lines of Go in this video on YouTube. Enjoy!

https://www.youtube.com/watch?v=Utf-A4rODH8

Do you use some other unknown container runtime? Have you written your own? Do you have any best practices you would like to share with the container 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.
In this edition we are going to showcase several solutions for developers to deploy Kubernetes clusters locally. Turns out there are a lot of them!
There are a lot of reasons why developers would want to run their cluster in their laptops: reducing latency and speeding up the development cycles are crucial factors for cloud-native apps. But it can also be useful for demos, training sessions and for quickly testing new ideas! The usual choices, mentioned here for the sake of completeness, are of course the venerable minikube (an integral part of the Kubernetes project) and Minishift (an open source Red Hat project). The thing is, minikube can be quite slow sometimes, and it requires an underlying virtual machine to run (usually VirtualBox as a cross-platform solution, or KVM for Linux hosts). Is there a better option to run a cluster locally?
1. The first one in the list is kind, also known as „Kubernetes in Docker“. Written in Go, available for Windows, macOS, and various Linux flavors and architectures. It is lightweight, extremely simple to install (just download the executable and run) and even easier to use (kind create cluster, export your KUBECONFIG variable and you are good to go). This tool has lots of potential; it is comprehensive, simple, and much faster than other options. Remember though, that the current version at the time of this writing is 0.5.1, and that many features (for example LoadBalancers) are not ready yet.
https://kind.sigs.k8s.io/
2. Another promising tool is Microk8s. It is an official Ubuntu project written in Python and shell script, steadily growing in popularity and contributions, but without any official release at the time of this writing. It even comes bundled with its own kubectl command, automatically configured to talk to your Microk8s cluster! And not only that; it also bundles Istio, Knative, Grafana, Kubeflow, Prometheus and many other tools out of the box. Being an Ubuntu project, it is based on Multipass and distributed as a Snapcraft package – of course! We have found, however, that the installation process is a bit cumbersome for macOS users (as it requires to manually provision a VM with Multipass before installing Microk8s). Other than that, it is reliable, simple and fast.
https://microk8s.io/
3. Nobody wants to miss on this market. That is why Rancher Labs has brought us k3s – an ultra-lightweight distribution of Kubernetes, targeting local development and IoT applications. And to make it even easier to use, they also created k3d, which runs k3s in Docker! Both k3s and k3d are written in Go. A simple k3d create will bring a new cluster to life, and after exporting the required KUBECONFIG variable, it is ready to be used with kubectl just like any other cluster. It looks really promising and it is available as version 1.3.1 at the time of this writing. However, in our experience it requires a bit more work to setup a complex cluster, since for example it doesn’t have a default storage class, and as such it can not provide any PVCs automatically.
https://k3s.io/
4. Since the release of Red Hat’s OpenShift 4 in May the industry has been waiting for a solution to deploy OpenShift 4 clusters locally, since Minishift is designed to work only with OpenShift 3. Well, Minishift has other issues as well; for example, the version of the Docker daemon bundled with it is 1.12, which means that multi-stage builds are not available. But the successor of Minishift arrived recently: it is called Red Hat CodeReady Containers and it is already available in version 1.0 beta at the time of this writing. Written in Go and available for Windows, macOS and Linux, it is the simplest way to run a complete OpenShift 4 cluster in your local laptop, batteries included.
https://github.com/code-ready/crc
5. Any other options? Of course! This field is incredibly dynamic, and new projects are popping up all the time; to mention a few: Docker Desktop with its „one checkbox“ integrated K8s for Windows and Mac; Banzai Cloud’s Pipeline Kubernetes Engine; Windmill Engineering’s Tilt; Kubermatic’s Container Engine; and NetApp’s Kubernetes Service… all working hard so that developing on Kubernetes does not suck!
https://blog.tilt.dev/2019/08/21/why-does-developing-on-kubernetes-suck.html
Do you use similar tools to run Kubernetes clusters locally? Are you satisfied with them? Do you have any best practices 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 are going to talk about GitOps, the new trend in the world of cloud-first apps and Kubernetes.
1. Our industry is famous for its buzzwords, trends, and hype. But the truth is, people cannot memorize computer industry acronyms anymore. And „GitOps“ appears to be just another one of those. The question then is, what is GitOps? Jack Wallen from The New Stack published a great article explaining what GitOps is. TL; DR: „GitOps is centered around using a version control system (such as Git) to house all information, documentation, and code for a Kubernetes deployment, and then use automated directors to deploy changes to the cluster.“ Push your changes to your repository, and watch your cluster rebuild itself continuously. But of course there is more than that!
https://thenewstack.io/what-is-gitops-and-why-it-might-be-the-next-big-thing-for-devops/
2. Still not entirely sure about what GitOps is, and how it could be useful to you? Fear not. Weaveworks (credited by The New Stack as the origin of the word „GitOps“) published a extensive GitOps guide, with pretty much all the information you need to understand, apply, verify and advocate for GitOps. At VSHN we use it internally to help us guide our customers towards the Holy Grail Of The Single Source Of Truth™®© and automated deployment. An invaluable resource to bookmark and review every so often!
https://www.weave.works/technologies/gitops/
3. The New Stack article that started this edition mentions very quickly something about „SOC 2 Compliance„. Even more important, according to the founder and CEO of Weaveworks, Alexis Richardson, „in GitOps, we MUST use continuous observation and verification, to enable app & cluster management“. For many regulated industries, like pharma, finance, and government institutions, that also means ensuring continuous compliance, and this article by Dave Farley explains how to achieve precisely that. Through automated CI / CD pipelines, teams can automatically generate audit reports, track human decision making, update documentation, and verify sign-offs. A fantastic resource!
http://www.davefarley.net/?p=285
4. Of course, no amount of validation, continuous integration, or verification will guarantee that you are building the right product (although you might be building the product right!) Jonathan Smart published an excellent piece about making sure that your team builds the right product. Jonathan defines four common anti-patterns found in many „agile“ organizations, and how to tackle them: „Local Optimisation & the Urgency Paradox“, „Milestone Driven Predicted Solutions“, „Headless Chickens“, and „Start starting“. Somewhere, right now, a project slows down because of one or many of these anti-patterns. Do not fall into the trap of misreading the Agile Manifesto into something it is not.
https://medium.com/sooner-safer-happier/agility-build-the-right-thing-69d316aeb56b
5. And to finish this edition, the tool of this week comes from none other than the Linux Academy: the list of free courses offered during September 2019 include some GitOps-related ones, such as DevOps Essentials, Git Quick Start, and System Tooling with Go. Excellent content for free! You have just run out of reasons not to implement GitOps in your daily workflows.

Would you like to share other GitOps-related links with us? Are you already using GitOps in your organization? Do you have any best practices 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 and making us think, laugh, or simply work better.
This week we are going to talk about OpenShift, the Kubernetes-based container technology by Red Hat.
1. Did you know that our APPUiO.ch platform was the first public multitenant OpenShift Service in Switzerland? VSHN is an official Red Hat Partner for OpenShift, and as such we have been continuously deploying and maintaining OpenShift clusters since 2015. But what is OpenShift, and how did it become such an important platform in such a short amount of time? Anton McConville and Olaph Wagoner wrote an excellent brief history of Kubernetes, OpenShift, and IBM at the IBM Developer Blog, providing all the information and context required to understand this revolution in the world of cloud native apps. The article covers the origins of the OpenShift project in 2011, its migration to Docker & Kubernetes around 2014, and the current state of the project in version 4 (released in May).
https://developer.ibm.com/blogs/a-brief-history-of-red-hat-openshift/

Gartner: Global IT spending in 2019 to top $3.79 TRILLION. Public cloud spending? $214 billion. Cloud is not about trading market share between AWS, Azure, Alibaba, or GCP; rather, it is about making that other ~95% of IT spending dramatically more productive. We have work to do

— Matt Asay (@mjasay) September 4, 2019

2. This month we will be talking a lot about OpenShift! For example, tomorrow (September 10th) we will be hosting the APPUiO booth in the Red Hat Forum 2019 Zürich. Next week we will be speaking about Serverless solutions at the Swisscom OpenShift TechTalk in Bern and later at the NetApp Technology Forum. And also, during the whole month we will be talking about APPUiO, Kubernetes and OpenShift at the CLOUD Conference 2019 in Bonn, Hanau, Hamburg and Munich. Make sure to drop by and say hi to our VSHNeers in place!
https://vshn.ch/vshn/events/
3. Want to try OpenShift 4 in your platform? Christian Hernandez from Red Hat provided a detailed yet concise quick start tutorial for OpenShift 4.1 recently, providing all the information required to install and configure an OpenShift cluster in your own infrastructure. But if you would like to run it in your laptop, for example to develop cloud-native apps, try Red Hat CodeReady Containers instead!
https://blog.openshift.com/openshift-4-bare-metal-install-quickstart/
4. At VSHN we use OpenShift and Kubernetes all the time. To such an extent that we even use it during our spare time! One of VSHN’s founders, Tobias Brunner, has written a fantastic blog post in his personal blog, about how he created a Point-of-Sale solution from scratch using Odoo on a Kubernetes cluster with Raspberry Pi nodes for the Urdorf Fire Department. Check it out!
https://tobru.ch/open-source-point-of-sales-pos-with-odoo/
5. The most visible and certainly one of the most useful parts of OpenShift is undoubtedly its web UI, allowing administrators to deploy, manage and scale applications with ease. But there are other similar projects providing web interfaces to perform those tasks in a Kubernetes cluster: Henning Jacobs provides a nice overview of the current state of web UIs for Kubernetes in his blog, highlighting major advantages and drawbacks for each: K8Dash, Kubernator, kube-ops-view, Octant, and many others!
https://srcco.de/posts/kubernetes-web-uis-in-2019.html
Would you like to share other OpenShift-related links with us? Are you already deploying your cloud-first apps in OpenShift? Do you have any best practices you would like to share with the community? Get in touch with us using the form below, 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 and making us think, laugh, or simply work better.
This week we are going to talk about Kubernetes security; hang tight, this is a hot topic and there is a lot of material in this edition!

1. We cannot start a security–related issue of VSHN.timer without mentioning the breaking news of a major security audit of Kubernetes, which raised 34 major vulnerabilities in about two million lines of code. The Cloud Native Computing Foundation mandated Trail of Bits and Atredis Partners to perform this audit, spanning from encryption to networking to storage to every other aspect of Kubernetes. This report triggered the immediate release of new versions of Kubernetes: 1.13.9, 1.14.5, and 1.15.2 – and then later 1.13.10, 1.14.6 and 1.15.3 to fix vulnerabilities in the net/http library of the Go language as well. It goes without saying that this step marks a major milestone in the history of Kubernetes and cloud-native apps.

https://www.theregister.co.uk/2019/08/06/kubernetes_security_audit/
2. All systems are as secure as their weakest part. This means that developers deploying applications in Kubernetes have to take care of a myriad of factors. For example, end-to-end encryption. Red Hat published a tutorial recently about how to configure secure end-to-end communications in cloud native apps. Since you are hardening your cluster, you might want to give developers the least possible level of privilege, learn how to properly get a shell to a kubernetes node, and learn more about etcd.
https://blog.openshift.com/self-serviced-end-to-end-encryption-for-kubernetes-applications-part-2-a-practical-example/
3. The risks of misuse and misconfiguration of Kubernetes are indeed huge. Take what Mate Ory from Banzai Cloud explains in this blog post for example. A badly configured (or downright malicious) kubeconfig file can leak confidential information such as keys and credentials, and even execute shell commands in a compromised cluster – while at the same time cleaning up its own traces! As a bonus, the Banzai team has released the kubeconfigurer tool to verify kubeconfig files for precisely those security issues. An absolute must read.
https://banzaicloud.com/blog/kubeconfig-security/
4. And just like with any other new and hyped technology, things can go wrong with Kubernetes. Very fast and very wrong. And not only from a security point of view. To stay updated (and to learn a few things that might help harden your cluster in the future) the Kubernetes Failure Stories website provides a compilation of public failure & horror stories related to our favorite cloud native technology. Worth a few facepalms. At least. And in case you did not get enough, well, this postmortem of Debian’s failed Docker registry move might make your day.
https://k8s.af/
5. To finish this unfortunately gloomy edition of VSHN.timer, here’s a link to the OWASP Container Security Verification Standard, a „community-effort to establish a framework of security requirements and controls that focus on normalizing the functional and non-functional security controls required when designing, developing and testing container-based solutions with a focus on Docker.“ In this brave new world of ours, we need more of these initiatives.
https://github.com/OWASP/Container-Security-Verification-Standard
Would you like to share other Kubernetes security-related links with us? Have you had suffered serious security incidents while deploying Kubernetes? Do you have any best practices you would like to share with the community? Get in touch with us using the form below, 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 and making us think, laugh, or simply work better.
This week we feature interesting articles about HumanOps, the next logical step in a path that leads to software made by humans, for humans.
1. How does one transition to DevOps? Does one become a DevOps engineer right out of school, or does one need prior experience in software development, IT administration or other tasks? Conor Delanbanque gives some good advice in an effective article.
https://devops.com/how-to-transition-to-become-a-devops-engineer/amp/
2. And once you are working in the DevOps field, what do you do? What does the „DevOps Engineer“ job title mean, anyway? To help us answer these questions, André Ilhicas dos Santos provides a comprehensive blog post with lots of interesting insight about our craft.
https://ilhicas.com/2019/08/11/What-you-as-a-Devops.html
3. Learning is primordial, but you knew this already. To keep a certain level of interest in our activity, to avoid dying of boredom, and, yes, to stay relevant in the job market, too! We in this industry read and learn every day – and that is the main reason you are checking out the VSHN.timer series every Monday, is not it? Silvia Botros explores in her article the various aspects around learning as engineers, including the important organizational factor: are companies willing to invest in the growth of their engineers? After all, you could even learn how to send IP packets over spaghetti!
https://blog.dbsmasher.com/2019/08/08/how-we-keep-learning.html
4. But we know that nothing lasts forever. DevOps is a career that simply did not exist 10 years ago. Back then we had sysadmins, and before that we even had „operators“ – a term popularized by both the Matrix franchise and the infamous BOFH series. What will be the next step in this continuous evolution? What will we call DevOps Engineers in 2030? Matthew Broberg from Red Hat wrote a very interesting article about how deep knowledge in one specific technology almost brought his career to a full stop.
https://opensource.com/article/19/8/plan-next-IT-career-move
5. In the meantime, we needed to learn how to manage the complexity of our Kubernetes clusters, and we found VMWare Octant to be a great addition to our toolbox. Here it is hoping it will help you too!
https://github.com/vmware/octant
Would you like to share other HumanOps-related links with us? Is your organization embracing HumanOps? Do you think it will become an important trend in the future? Let us know in the comments below, and see you next week for another edition of VSHN.timer.
PS: did you know that there is a Swiss HumanOps meetup? Join the group and stay tuned for the first meeting to be announced soon.

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 and making us think, laugh, or simply work better.
This week we will talk about Quality, the Saint Graal of software characteristics, particularly critical in these days of 12 factor apps.
1. One of the core tenets of DevOps is Continuous Integration and Continuous Deployment, usually referred to as „CI/CD“ and usually implemented as „pipelines“ where code is built and put in production in a series of automated procedures. Are then „Continuous Verification pipelines“ the next step? At this moment in time, hopefully, most CI/CD pipelines should be at least executing a set of automated tests (unit tests, functional tests, etc) before the code is sent to production. Yes, hopefully. Let us see if the concept of Continuous Verification stands the test of time.
https://www.verica.io/continuous-verification/

Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in.

— Michael Stahnke (@stahnma) August 21, 2015

2. Some breaking and good news from the Cloud Native Computing Foundation: the Flux operator officially joined the CNCF! Flux allows developers to keep the state of their clusters using state stored in Git repositories; the synchronization is automatic and does not require another step. Having the support of the CNCF will most certainly bring this project to prominence and maybe to become the next gold standard.
https://www.weave.works/blog/flux-joins-the-cncf-sandbox
3. No matter how careful teams are, things go horribly wrong sometimes. It is the case for Monzo recently, a startup in the financial services sector. Their post-mortem article is an example in detail and accuracy, worth a read in spite of its length. Apparently the problems began during an update of their Cassandra systems, and it all went downhill from there. Building robust systems is complex enough given the myriad of movable parts in place. And more often than not, our perception of complex system is simply guided by myths. Can we break the cycle? Can teams find an equilibrium and manage all of those moving parts?
https://monzo.com/blog/2019/09/08/why-monzo-wasnt-working-on-july-29th
4. Continuous integration can be much more complicated than it seems at first sight… particularly in big enterprises. This fascinating interview of Janye Groll, CEO of the DevOps Institute, and Wayne Ariola, chief marketing officer for Tricentis by Cynthia Dunlop of The New Stack, raises lots of interesting points. How can you reach „continuous delivery“ when organizations have tight risk management measures in place? What about their current contracts with vendors and providers? What about regulations that must be met every time a new version of their system goes live? For many companies, one just cannot deploy a new version on each new commit.
https://thenewstack.io/continuous-testing-for-a-devops-world/
5. And the tool of the week is Locust, an open source loading tool to simulate huge loads to your systems (and whose name reminded us of a classic progressive rock song, by the way). Instead of using configuration files, Locust uses plain Python code to simulate interactions on an application, and then simulates millions of simultaneous users on our clusters. Let’s evaluate the scalability of our systems (or lack thereof) in real time!
https://locust.io/
Would you like to share other quality and testing links or tools with us? Is your organization embracing CI/CD, GitOps, testing (hopefully!) or Flux? Let us know in the comments below, 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 and making us think, laugh, or simply work better.
This week we feature interesting articles about DevOps, one of the most widely misunderstood and misquoted words in the modern business of software.
1. According to Wikipedia, the term „DevOps“ is barely ten years old. No wonder then, in these days when every company is a software company and software is eating the world, to see business leaders struggling with the „DevOps“ buzzword. Companies with a very „vertical“ flow of information (read: hierarchies) will have a harder time to adapt to DevOps, as it is more a state of mind than a set of practices. What to do when your business software was driven by decades of disgruntled consultants, remote offshore providers, or non-agile project managers, resulting in large silos of information within organizations? Steve Howe could not say it better: silos are the greatest enemy of DevOps.
https://medium.com/@daryn_74143/how-to-do-devops-when-you-have-no-idea-who-the-devs-are-f156d42aab8f

We told them six months ago to do the DevOps and they’re still not doing with the DevOps. What’s wrong with them? can you fix them?

— Rob England (@theitskeptic) July 3, 2019

2. The word DevOps is usually associated with software running in „Cloud“ premises, as „backend“ or as „server-side“ stuff. The truth is, DevOps is also enabling a smartphone app near you! Bitrise is starting a series of blog posts about DevOps in mobile app development. As a topic dear to the author of these lines (an ex mobile developer), we could not be happier to see modern DevOps practices coming to the forefront. Ever setup a CI / CD pipeline to build iOS or Android apps? All we can say is, this field needs more DevOps thinking.
https://blog.bitrise.io/learn-more-about-mobile-devops-on-bitrise
3. But what about DevOps security? Higher frequencies of deployments and a frantic pace of new features increase the chance of major security incidents. Unfortunately, many software engineers still lack proper security training, so to help you here are some nice DevOps and DevSecOps security checklists, to bookmark and use and reuse. But before you do, pay attention to what Kacy Zurkus says: DevOps security is a people and culture problem, and not merely a technical one. Are you ready to change your culture?

4. If you just do not know where to start, Jeremy Morgan from Pluralsight published a excellent list of 10 books about DevOps you might want to check out. It not only includes technical books, but also some novels and even business titles. We at VSHN we are great fans of „Effective DevOps“ and „Continuous Delivery“ – the classics in the genre and primary resources as far as we are concerned. But we did not know that the 10th book in the list, „The Goal,“ was first published in 1984! Indeed, everything is a remix.
https://dev.to/pluralsight/the-top-10-books-on-devops-you-need-to-read-45m2
5. It was not enough to have DevOps, now we have to deal with its offspring, GitOps, proposing „push to deploy“ scenarios, where automation is pushed (no pun intended) to the extreme. How to couple GitOps with Kubernetes deployments? Here is a Github project with „an opinionated working solution leveraging Kubernetes and proven GitOps techniques to have a resilient, composable and scalable Kubernetes platform“ that might provide some answers.
https://github.com/edgelevel/gitops-k8s
Would you like to share other DevOps-related links with us? Is your organization embracing DevOps? Would you like to embrace it but you just do not know where to begin? Or do you think it is just another hype-laden buzzword? Let us know in the comments below, and see you next week for another edition of VSHN.timer.
PS: Speaking about DevOps, here is a microservices & DevOps meetup in Zürich next month you might be interested to attend.

Welcome to the new VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system and making us think, laugh, or simply work better.
This week we feature a few articles stating what is in everyone’s mind: Kubernetes is becoming the new standard platform for cloud applications.
1. The Register published an interesting interview with Pivotal’s CEO about the „inevitability“ of Kubernetes. It is an interesting article, with both positive and negative points, highlighting gains and pains in equal measure. Adopting K8s requires a substantial investment of time and money, something many companies jumping on the „cloud“ hype wagon do not always take into account. In any case, the word „inevitability“ brings both Thanos and Agent Smith to our minds, and we just hope nobody will snap the fingers of the Infinity Gauntlet right in the middle of that deployment into production. Just look at the stock price that appears at the end of that article to see what we mean.
https://www.theregister.co.uk/2019/07/29/pivotal_ceo_interview/
2. The pain points can be many, and not all teams are ready to handle them properly; this is not a fault of those teams, but most often a cause of the relative youth of the ecosystem. Case in point: Grafana’s own account of how badly configured pod priorities caused a production outage. K8s is fun and exciting and has lots of promise, but as an industry we are all still learning from mistakes, and this is a natural process. Thankfully the Grafana team could restore the systems after only 26 minutes and without any data loss – their story is a remarkable one and absolutely worth a read.
https://grafana.com/blog/2019/07/24/how-a-production-outage-was-caused-using-kubernetes-pod-priorities/
3. According to David Carboni, the prize of inevitability is invisibility. Well, actually David said „ubiquity,“ and we hope he does not mind us shortening the lexical distance between those two words. In the tag cloud generated by heated debates, there is one major thing everybody seems to agree about K8s: declarative state is the way to go. Describe how your system should look like, and let the machine decide how to implement it in the best possible way. And those YAML files are enabling a depth of communication between architects, developers and operation teams like we have not seen before. And this, in turn, will make K8s just another POSIX.
https://levelup.gitconnected.com/why-kubernetes-will-disappear-10ffcfb39f01
4. And what a platform K8s has become. If you have any doubts, just check this review of Kubernetes tools by Ellen Körbes from Garden.io. An amazing compilation with lots of cool new shiny toys to install and run and try and test. We do not know about you, but we are certainly testing them right now.

5. To complete the list above, here is a cool new tool we have recently discovered: Monday, a CLI executable (written in Go, duh!) that creates a hybrid local/remote configuration for applications written in several programming languages, enabling us to run part of our clusters locally and the other parts remotely. Really cool!
https://github.com/eko/monday
Do you have any cool links to share with us? What do you think about Kubernetes becoming the next POSIX? Do you think it is inevitable? Let us know in the comments below, and see you next week for another edition of VSHN.timer.