KubeConEU 2020 - Day 2
Tags: conference, kubernetes, cloud, series
Published: 2020-10-01 13:37:47

---
title: KubeConEU 2020 - Day 2
published: true
description: My journey through KubeConEU 2020
tags: conference, kubernetes, cloud, series
series: KubeConEU 2020
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/ejhxzygy7wo26kxvpthc.jpg
---

The journey continues! Day 2 to 4 where packed with talks! I tried to create briefs from each one I followed.

From Day 2 onward the talks where early and late in the afternoon, leaving space for keynotes in the middle. With that many interesting talks, I have to admit I skipped all keynotes after the first one in Day 2, but I'm watching them on-demand (it was easier to interact with speakers timely after their talks, as there were no talk dedicated channels but topic dedicated channels, so following conversations long after the talk was complex at times).

## Deliver Your Cloud Native Application with Design Pattern as Code

[Talk link](https://kccnceu20.sched.com/event/ZeiY?iframe=no)
Who is for: Ops, Backend
by [@JunMakishi](https://twitter.com/JunMakishi), [@TAR_O_RIN](https://twitter.com/TAR_O_RIN)

As organization embrace the Cloud and it's tools, managing fragmentation becomes more and more complex. The idea of applying design patterns to create composable and reusable infrastructure components is very cool. It also allows to abstract in a reusable way different cloud provider patterns. 

They integrate **pipelines** in the equation, which is awesome. Flexibility of pipelines is one of the key advantages of being in the Cloud, leveraging that is very powerful.

It's not a one-size-fit-all approach, but their solution is inspiring. Based on Infrastructure as a Code and [CueLang](https://cuelang.org) for configurations.

The talk explores a powerful concept: **configuration as data** >> **configuration as code**.  
I agree! 

{% twitter 1202365463298101249 %}

Their solution does not take into account state management, that should be separately handled (they use Pulumi, previously they used Terraform).

{% youtube PHajuKqjNs8 %}

## Kubernetes Patterns

[Talk link](https://kccnceu20.sched.com/event/ZerV/kubernetes-patterns-roland-huss-red-hat?iframe=no)
Who is for: Backend
by [@ro14nd](https://twitter.com/ro14nd)

Companion book: _Kubernetes Patterns_ (Free download https://k8spatterns.io/)

Nothing particularly new to me, I've had my chance to review and study Kubernetes patterns some time ago.

Worth checking out if you're a developer using K8s for app delivery. The book is definitely to be downloaded for study and future reference.

{% youtube eJmNSYvelSw %}

## Progressive Delivery

[Talk link](https://kccnceu20.sched.com/event/ZesH/progressive-delivery-in-kubernetes-carlos-sanchez-adobe-viktor-farcic-cloudbees?iframe=no)
Who is for: Ops, Backend
by [@vfarcic](https://twitter.com/vfarcic), [@csanchez](https://twitter.com/csanchez)

Progressive delivery is a term to describe deployment techniques to avoid common all-or-nothing deployment pitfalls. 

The goal is to shift traffic slowly from the old to the new version, being able to roll back immediately in case of unexpected behaviours of the new deployment.

Avoid downtime, limit the blast radius, ship code faster!

I was positively impressed by the visual explanations of techniques. The concepts were clear to me before the presentation, but have been explained so well it has been a pleasurable review.

> Monitoring is the new testing

Today monitoring allow to know when users are experiencing issues **and react automatically**.

Demo time focus on [Istio](https://istio.io/) and [flagger.app](https://flagger.app/).

How to manage databases with progressive delivery? 
- Use Cloud hosted solutions
- Make you app **always** backward compatible
- Only non-breaking database schema changes.

{% youtube Jf29YXu1Q48 %}

## Build an Automatic Canary Release Pipeline in a Kubernetes-native Way

[Talk link](https://kccnceu20.sched.com/event/Zeie/build-an-automatic-canary-release-pipeline-in-a-kubernetes-native-way-ying-chun-guo-ibm)
Who is for: Ops
by Ying Chun Guo

I was a bit mislead by the title of this talk. The focus is on [Knative](https://knative.dev/) (a serverless platform on top of Kubernetes) and [Tekton](https://tekton.dev/) (a Kubernetes-native CI/CD system). Truly Kubernetes-native but very "locked in".

Seeing how the two systems play together has been interesting, but unless you are planning to adopt such technologies there is little knowledge that you can reuse in other environment.

{% youtube xK1QD_aZWq8 %}

## Handling Container Vulnerabilities with Open Policy Agent

[Talk link](https://kccnceu20.sched.com/event/Zekd/handling-container-vulnerabilities-with-open-policy-agent-teppei-fukuda-aqua-security)
Who is for: Ops, Security
by [@knqyf263](https://twitter.com/knqyf263)

This has been one of the most interesting talk I've followed.

> Scanning for vulnerabilities does not scale. In 2019 there have been little less than 50 vulnerabilities **per day**. 

How can the team keep up with that? By reducing noise and focusing on **what matters to us**. 

Use Open Policy Agent (OPA) to define **how** to handle vulnerabilities discovered by a scanner. This allows to create policies to handle vulnerabilities based on internal knowledge and requirements.
 
[Trivy](https://github.com/aquasecurity/trivy) has direct OPA integration.

`trivy-enforcer` is a custom K8s controller that allows enforcing policies on images to be deployed on K8s. Still experimental, looks awesome!

{% youtube WKE2XNZ2zr4 %}

## Architectural Caching Patterns for Kubernetes

[Talk link](https://kccnceu20.sched.com/event/ZerY/architectural-caching-patterns-for-kubernetes-rafal-leszko-hazelcast)
Who is for: Backend
by [@RafalLeszko](https://twitter.com/RafalLeszko)

Do you happen to need caching data in your services? Generally, is quite a common need.

The overview of caching pattern was quite complete but the talk felt centred around promoting the speaker company product more than giving a solid understanding of different caching patterns.

Still worth to watch if you want an overview of caching patterns or if you're interested in the product (Hazelcast).

{% youtube poO6KDRHAL0 %}

## Tracing is For Everyone: Tracing User Events with GraphQL and OpenTelemetry

[Talk link](https://kccnceu20.sched.com/event/ZeiJ/tracing-is-for-everyone-tracing-user-events-with-graphql-and-opentelemetry-nina-stawski-splunk)
Who is for: Frontend
by [@ninastawski](https://twitter.com/ninastawski)

This talk is presented by a UI engineer! It's so interesting to see tracing applied to frontend because can really help understand where customers are having issues using your application.

Why only Backend and Ops should have the cool tools? [OpenTelemetry.js](https://github.com/open-telemetry/opentelemetry-js)

> UI is much more than a "service". Users do lots of things in UI and with complex UI apps (microfrontends, complex journeys) tracing **is powerful**.

Collect actions in UI then send to backend and collect (in [Zipkin](https://zipkin.io/)). If you want to follow along the demo, a GitHub repo [is provided](https://github.com/nstawski/opentelemetry-graphql).

By carefully tagging traces is possible to correlate **frontend and backend** traces to look at the entire user journey. **COOL!**

{% youtube 8Ldp9w8wm-U %}

## Five Great Ways to Lose Data on Kubernetes (And How to Avoid Them)

[Talk link](https://kccnceu20.sched.com/event/Zet6/five-great-ways-to-lose-data-on-kubernetes-and-how-to-avoid-them-robert-hodges-altinity-ltd)
Who is for: Ops
by [@dbcicero](https://twitter.com/dbcicero)

Database data resiliency is always an interesting topic for me. Nobody cares if the app is up and the code works if the database is broken.

The talk had cool tips, and some very nice troubleshooting/discovery commands. Highly recommended!

It starts with a clear explanation on Kubernetes related risks for *stateful* applications and mitigations.

The main mentioned topics have been: replicas, affinity, distance, ephemeral storage and operator error.

**Replicas**

Replica is one of the ways to avoid node failure.

How does Replicas cope with *blast radius* (how fare away you need to be to not be affected by a failure)?

**Affinity**

The process of requesting different replica to be nearby or distanced. Kubernetes supports [Pod affinity](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/) natively.

**Distance**

Protect replicas using distance (affinity/anti-affinity).

Take backup in object storage (it's easy and durable).

How does distance cope with *blast radius*? How to protect across regions or K8s clusters? **It's complicated**: it's not just a data problem, is a resource problem too (think load, DNS). (This part was out of scope for the talk, unfortunately!)

**The persistent volume that doesn't**

In Kubernetes ephemeral storage is a feature. Unless you want it to be persistent 😅

A pod cannot understand if storage is ephemeral or not.

Persistent Volumes are not enough if you don't use them! When you **expect** your Pod to use persistent storage, **verify** it writes data to be persisted to the proper mount point, otherwise ephemeral storage is used.

**Fat fingers of fate**

The saddest one. When an operator **deletes** applications. In Kubernetes deleting workloads is very easy. Once an application is deleted, dynamically provisioned persistent volumes (like the ones created by cloud provider integrations) are **deleted** by default. 

But fear no more, you can avoid that [changing the Reclaim Policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) to `Retain`. You can  achieve the same by creating a new `StorageClass` with `Retain` policy and use that.

{% youtube zW7gLyPln3w %}

## Escaping the Jungle - Migration to Cloud Native CI/CD

[Talk link](https://kccnceu20.sched.com/event/Zesu/escaping-the-jungle-migration-to-cloud-native-cicd-anton-weiss-otomato-software?iframe=no) 
Who is for: Ops, Backend
by [@antweiss](http://twitter.com/antweiss)

> When a company starts it's journey, there is a blank slate. Then, after a while, you get in the jungle, where everything is in your stack and there is tech debt everywhere.

It's time to find [the Golden Path](https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/).

Golden Path is not "the only" path, but it makes easier for the organization to work together. It's the supported path, out of it, you're on your own.

Meanwhile, you may want to build _Cloud Native_ apps. And what about CI/CD? What is a _Cloud Native_ CI/CD?

"Avoid e2e test at all, they are very brittle. Adopt [Contract Testing](https://www.martinfowler.com/bliki/ContractTest.html) instead."

When building the Golden Path, build the map of **where** we are going and embed it in the pipelines.

This one has been one of the most interesting for me, as surfing the amount of different tech stacks in a company can be incredibly daunting and I can see the Golden Path value proposition.

{% youtube kgVe5cWSMZQ %}

--- 

That's the end for Day 2! Any talk you think is missing? Let me know in the comments!