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.
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
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?
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)
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)
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)
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
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 ...