If you've gone all-in on Kubernetes (or are going all-in) for your container-based platform, I provided some debugging tips based on an excellent @rawkode#Klustered session 🔧
And if you're looking to get started with the new @Docker Desktop extensions, then why not check out the Telepresence extension for fast feedback when developing and testing container-based microservices 💻 ⚡ ☁️
If you're looking to build on your Docker Desktop extension for Telepresence setup, why not embrace @CloudNativeFdn's @buildpacks_io for an easy build with hot reload? 🔥
I've enjoyed using buildpacks since the days of Heroku. Here's my latest take:
Think about coupling and cohesion when designing microservices (yeah, yeah, I know, but I mean seriously think about this, and even do some upfront design) 🎨
Currently thinking about how API gateways and service mesh can work together, now and in the future:
- North-south traffic
- API as a product
- Migrating to the cloud
- Zonal architecture vs zero trust
A thread 🧵 👇
Traditionally API gateways have handled north-south (ingress) traffic and service meshes have handled east-west (service-to-service) communication
We used to think external access and choose an API gateway. And recently we used to think internal access and choose a service mesh
Increasingly, with a focus on design thinking (and rapid product iteration), migration to the cloud, and enhanced security, the boundary between API gateway and service mesh is becoming less clear
I've recently been seeing increased chatter about "internal developer relations" or "internal devrel" roles 🤔
I'm also bumping into this role in companies we work with, alongside "dev enablement" and "developer experience (devex)" teams
Want to know more? Read on 🧵 👇
Having worked in externally-facing devrel roles for a while, this is my definition of devrel
DevRels bridge the gap between technology and user adoption:
- Generating awareness
- Education
- Creating tech demos
- Community building
- Empathizing with devs
- Acquiring feedback
A few of you may be thinking "but this looks like several roles across marketing, engineering, product ownership, and program management"
To which I reply: "yes" 😁
DevRel is a challenging role, and you'll wear many 🎩 s. It's also an extremely rewarding role
In preparation for fixing broken Kubernetes clusters live on @rawkode's #Klustered event, I reminded myself of some of the core K8s debugging commands and techniques
Here are my top 10 tips for platform engineers debugging Kubernetes and the machinery underneath the covers 🧵 👇
First off, use kubectl to take a look at the cluster infra:
$ kubectl get nodes
$ kubectl cluster-info dump
These commands typically give you a good idea of where to start debugging, e.g. broken nodes, infra issues, resources
If kubectl doesn't work, it's time for some Linux debugging! SSH to the control plane node and run:
$ ps aux | grep kube
This will show you if core components such as the kublet, kube-apiserver, kube-scheduler are up and running