Over the past few months, I’ve been very focused on GitOps, becoming actively involved in the GitOps Working Group as a contributor in the GitOps Principles Committee. GitOps is a model that represents the next stage in evolution in terms of application and configuration delivery, particularly when we look at it in the context of Kubernetes. Kubernetes with its CRDs and powerful API, is growing to become more than just a container orchestrator, rather a control plane for… basically, everything.

The struggle with Data Don’t let anybody fool you, data is tough. It’s difficult to move around, and the more voluminous it gets, the harder it becomes to make sure it’s clean and reliable. Trying to solve data consistency and quality issues always feels to me like finding needles in haystacks, except it’s not haystacks, it’s 50-ton balls of mud. It gets even more complicated when you incorporate ML into the mix.

Before going into OpenTelemetry, the CNCF Project, I want to use the opportunity to also discuss some of the more fundamental concepts as to what telemetry and observability mean, as well as elaborate on the recent changes the industry has experienced in terms of evaluating performance, availability and more importantly reliability of digital products. What is telemetry and observability? Telemetry, in its simplest form, means gathering data that can be used to understand performance and utilization of your application across its multiple components, in other words, proactively and programmatically deliver data that can be used to track the behavior of your system as requests move throughout services.

Click here if you want to go straight to the technology insights. The non-technical The new (virtual) normal I have to say I love virtual conferences. Yes, there definitely is a void in terms of interaction and hanging out with friends and community. Yet, I must admit, I struggle with engaging people that I have not had some form of contact before in person on hallways during on-site conferences. Reaching out to people in Slack or whichever communication platform chosen by the organizers is dramatically friendlier to a person of my character and allows me to have remarkably better results in finding new contacts and growing my network.

Thinking in terms of systems and cycles Building and evolving an organization has components of both science and art. This description is not unusual when talking about people, and even more so when talking about systems made up of humans. Humans are quite complex, and none of us came with an instruction manual. The dynamics of human interaction happen at many levels, and to drive people in harmony towards a common objective requires tremendous effort and a bit of magic.

The endless search for a simpler workflow HashiCorp announced in this last 2020 HashiConf the release of a new open source project called Waypoint. Waypoint’s value proposition is: to provide developers with a way to declare, in a single file, a build/deploy/release workflow that can work across any platform. In this post I’ll walk you through the process of getting setup, and will share some of my findings and opinions as to how waypoint fits in the cloud native engineer’s toolchain.

Kubernetes keeps expanding its reach, and the edge is no exception. When thinking edge and IoT, footprint becomes a critical issue. You must make sure that whatever you are running to orchestrate and manage your workloads is as lightweight as possible. Today we’ll look at how to automate running a single node Kubernetes “cluster” (I know, single node is not a cluster, but you get the gist) with K3S by Rancher, on top of Fedora CoreOS.

Let’s get experimenting Welcome to Part 2 of my series on the Open Application Model and Crossplane. If you just got here and want to learn what OAM and CrossPlane are, start with part 1 of this series for an overview of both. In this experiment we will take Gooogle’s “Online Boutique” and transform one of its services into a OAM / Crossplane framework based solution! The original version on the sample solution can be found in this GitHub repo but we will be working on a forked and modified version of it which you can find in my forked copy of the repo here.

An event driven world The world of systems architecture has been through accelerated change. The cloud, containers and container orchestration, as well as entirely new paradigms for how you build and deploy software such as serverless architectures, have dramatically changed the patterns that govern how systems and components within those systems interact with one another. The shift away from monoliths, and the ever-increasing scale that software needs to endure, together with an also growing amount of data as driver to a lof of this, have directed plenty of solution and systems architects towards embracing an event driven approach to their designs.

Before we get started on Podman, let’s do a quick overview of containers in general. The world before and after Docker For most, hearing the word “containers” immediately brings up Docker to mind. Docker was not the first container initiative in the Linux world, but it did come to breach the gap between containers and developers, and brought the concept to the mainstream. However, initiatives and technologies to isolate running processes and provide boundaries and resource control inside a linux system exist all the way back to 1979 when chroot was first introduced.