Developing cloud native applications bring in a lot of complexities for developers. Without using tools to compensate these complexities, you will not become very efficient. Additional, cloud developers often suffer a rising frustration, by fighting these problems. Before I push my code into Git, I want to test different things in my cloud environment. Therefore it is essential to have a fast and easy round trip. A classic round trip starts by writing or generating code, create a Docker image, deploy it into Kubernetes and test or remote debug the application in Docker or in Kubernetes. Without some elementary tools, this round trip will not be very fast or simple and therefore error prone. This Lab will show you some open source tools, making your live as a developer more easy. Short demos will demonstrate the simple handling of these tools. Starting point is the generation of a MicroProfile and a SpringBoot application. By using the different tools (e.g. Helm, Shell completion, kubectl cp, Ksync, Stern, Kubefwd, Telepresence, …) on these applications, the complete round trip will be shown. Most of these tools can also be used with other programming languages. Every tool works on its own which makes it easy to switch between these tools. Finally you will get an evaluation of these tools and I will show you an outlook on tools which are more focused on larger developer teams.

1. Developer Experience Cloud Native
-
From Code Gen to Git Commit
without a CI/CD Pipeline
Michael Hofmann
https://hofmann-itconsulting.de

2. Developer Experience Cloud Native
generate/create
code
Docker image
deploy to
(local) K8S
test and
debug
Git push

3. Developer Experience Cloud Native
New challenges
●
Docker image
●
K8S deployment
●
K8S environment (DNS, env vars, volumes, …)
Efficient roundtrip without tooling?

4. Developer Experience Cloud Native
Why should we develop in a cloud-native way?
●
delivering and deploying
●
new K8S environment brings new bugs
●
dependencies to local system
●
local system with different versions and behavior

5. Generate/Create Code
MicroProfile Starter
●
Only Maven
Spring Initalizr
●
Maven
●
Gradle

6. Generate Docker Image
Build image with Docker Daemon?
●
Security
●
Scalability
Dockerfile or proprietary description?
Maven/Gradle plugin or standalone tool?
On build server or in K8S?

7. Maven:
docker-client (Spotify)
docker-maven-plugin (Spotify)
dockerfile-maven (Spotify)
docker-maven-plugin (fabric8)
jib-maven-plugin (Google)
Generate Docker Image
started with 10+
Maven plugins for
Docker
today: 2 still exist

8. Generate Docker Image
Gradle:
gradle-docker (Palantir)
jib-gradle-plugin (Google)
gradle-docker-plugin (Benjamin Muschko)

9. Generate Docker Image
Standalone Tools (emerging):
●
BuildKit (Docker) (next generation ‘docker build’)
●
Kaniko (Google)
●
Buildah (RedHat)
●
Source-to-Image (RedHat)
●
Makisu (Uber)
●
...

10. Generate Docker Image
Big topic on it’s own!

11. Generate Code and Docker Image
Demo

12. Deploy to (local) K8S
Local K8S
●
Minikube
●
Docker Desktop
●
Minishift (OpenShift < 4.x)
●
CodeReady Container (OpenShift 4.x) (since
19.10.2019)

13. Deploy to (local) K8S
same situation as Maven/Gradle plugins?
Draft (Microsoft), Gitkube, Ksonnet, Metaparticle,
Forge, ...
But! New Kids on the Block!
Skaffold, Helm, Kustomize, ...

14. Deploy to (local) K8S
Helm 3 (13.11.2019) (Microsoft, Google, Bitnami)
“The package manager for Kubernetes”
Now without Tiller!
Manage K8S applications
Create own Helm charts or use existing
(Helm Hub https://hub.helm.sh)
CNCF Survey
2018:
Helm usage 68%

15. Deploy to (local) K8S
Interaction with K8S:
A lot of shell commands necessary ‘kubectl’-ing
(and a lot of ‘yaml’-ing)
Simplify: bash completion
(https://github.com/scop/bash-completion)

16. Deploy to (local) K8S
Demo

17. Test and Redeploy
simplified testing:
Kubefwd
(https://github.com/txn2/kubefwd)
„Bulk port forwarding Kubernetes services for
local development“

19. Test and Redeploy
simplified log analysis:
Stern
(https://github.com/wercker/stern)
„Multi pod and container log tailing for
Kubernetes“

20. Test and Redeploy
Redeploy:
Same round trip as
before or shorter?
kubectl cp
Precondition: Can
container reload new files?

21. Test and Redeploy
Ksync
(https://github.com/ksync/ksync)
similar functionality as kubectl cp, but
●
installs DaemonSet in your K8s cluster
●
works bi-directional
●
local watch process keeps local folder and pod
folder in sync
●
new pods will also be synced (scale --replicas=2)

22. Test and Redeploy
Demo

23. Debugging
Remote Debugging with your IDE
Squash (https://github.com/solo-io/squash)
“Debug your microservice applications from your terminal
or IDE while they run in Kubernetes”
Debugging across multiple services
also for Istio debugging
IDE support so far: VS Code (IntelliJ and Eclipse)

24. Debugging
Telepresence
Cloud Native Computing Foundation sandbox
project

25. Debugging
Telepresence
●
debugging a service mesh
●
substitutes a two-way network proxy for your K8S pod
●
proxies data from K8S environment (e.g., TCP
connections, environment variables, volumes) to the
local process
●
local process has its networking transparently
overridden so that DNS calls and TCP connections are
routed through the proxy to K8S

26. Debugging
Service Application Pod
Telepresence Pod
Deployment
Deployment
K8S
Telepresence Shell
swap
VolumeEnv
Env
Volume
Local

27. Debugging
Demo

28. The Big Players
Skaffold (Google)
„continous build & deploy on
code changes”
basis for commercial product
“Cloud Code“
daemon watches source
workflow-config (skaffold.yaml)
apiVersion: skaffold/v1
kind: Config
build:
artifacts:
- image: gcr.io/k8s-skaffold/image
custom:
buildCommand: build.sh
dependencies:
paths:
- .
deploy:
kubectl:
manifests:
- ./k8s/**

29. The Big Players
Kabanero (IBM)
supports development, architecture and
operations
platform architect designs platform
solution architect provides software stacks (PaaS)
developer can use predefined stack
IDE tools
TM

30. Final Thoughts
steep learning curve (Docker, Kubernetes)
new responsibility of a developer: deploy to Kubernetes
you have to deal with it, especially in solving environment errors
shown tools are easy to handle and make live of a developer
easier
selected tools should not interfere with each other

31. Final Thoughts
tools come and go; maybe you sit on the wrong horse
biggest challenge: find the right tool for a special purpose
there is no single golden bullet: but stay in sync with your CI/CD
pipeline; maybe you can use the same tools (e.g. Helm, ...)
as always: documentation could be better
the big companies smell a deal ...