Put the dev back in devops - Cloud-native at local speed! - RH Summit 19
0 likes361 views
The document discusses various tools and frameworks for improving developer experiences in cloud-native environments, especially focusing on Kubernetes. It compares different tools like OpenShift's Odo, Microsoft's Draft, and Google's Skaffold, highlighting their functionalities and limitations. The overall message emphasizes the necessity of enhancing developer operations in DevOps and making Kubernetes more accessible and user-friendly.
Put the dev back in devops - Cloud-native at local speed! - RH Summit 19
- 1. Put the Dev back in DevOps: Cloud-Native at Local Speed!
- 4. @jorgemoralespou @jankleinert Put the Dev back in DevOps: Cloud-Native at Local Speed!
- 16. https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/ KUBERNETES IS THE NEW KERNEL
- 17. https://twitter.com/kelseyhightower/status/1088828102480781313 KUBERNETES IS THE NEW SYSTEMD
- 19. https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/ KUBERNETES IS THE NEW APPLICATION SERVER
- 25. The Kubernetes platform for developers
- 33. Intuitive, Easy to use
- 34. Simple language
- 35. Fast
- 36. Inner loop
- 37. In-Context
- 40. OpenShift-Do (aka. odo) A developer friendly command line tool INTRODUCING:
- 43. $ odo create java $ odo push openshift
- 45. Designing a CLI is easy. Effective CLI design is difficult
- 46. “If you are using a product that combines enterprise-grade functionality with an unusable experience, then your life will be filled with frustration and pain” Justin Baker “Devs are people too”@medium
- 49. Draft (by Microsoft Azure) ● Process: ○ Builds locally Docker images (Packs provides Dockerfile) ○ Push image to registry ○ Deploys via helm Chart ● No parameterization to: ○ How application is built ○ How application is run ● Requires: ○ Helm tiller (server side) ● Really difficult to use and buggy ● Last release: Aug 27th 2018, v0.16.0 Feels abandoned project https://draft.sh/
- 50. Skaffold (by Google Container Platform) ● Process: ○ Builds locally or in-cluster Docker images (user needs to provides Dockerfile, Bazel or Jib/Maven) ○ Push image to registry ○ Deploys via helm Kubectl, Kustomize, Helm Chart ● No parameterization to: ○ How application is built (Expressed in Dockerfile, Bazel, Jib) ○ How application is run (Expressed in k8s resources) ● Supports watch for changes and auto-rebuild/deploy ● Allow to deploy to different environments (profiles) but this feature is not very portable ● Really difficult to use for non simple use-cases ● Last release: April 12th 2019, v0.27.0 https://skaffold.dev/
- 51. gitkube (by Hasura) ● deploy code to k8s cluster (automates build-push-deploy) ● git push to deploy, no dependencies on your local machine ● needs dockerfile, k8s manifests in the git repo, gitkube on cluster ● Last release: November 12th 2018, v0.3.0 https://gitkube.sh/
- 52. Squash ● Only for debugging ● Requires server side components (installed with cluster-admin) ○ Requires a privileged DaemonSet ● Integrates with popular IDEs ● Supports Go, Python, Node.js, Java and gdb ● User must ensure application binaries inside the container image are compiled with debug symbols ● Doesn’t modify deployments to prepare them for debugging ● Really difficult to use ● Last release: April 9th 2019, v0.5.8 https://squash.solo.io/
- 53. Telepresence ● Only for development to connect a local service to services in the cluster ○ Telepresence imposes some network latency ● It provides connectivity via a side-car process - sshuttle, which is based on SSH ○ More intrusive dependency injection mode with LD_PRELOAD/DYLD_INSERT_LIBRARIES is also available ● Many local additional dependencies: ○ python 3.5, openssh, sshfs, conntrack, iptables, torsocks,... ● Really difficult to use (and buggy) ● Last release: April 2nd 2019, 0.98 https://www.telepresence.io/
- 54. KSync ● Ksync synchronizes application code (and configuration) between your local machine and the container running in Kubernetes ○ It aims to improve iteration time for app development by eliminating build and deployment steps. ● DaemonSet installed on the server that provides access to each node's filesystem ● ksync only handles volumes that are mounted using the docker graph driver directly ○ Not PVs ○ No CRI-O ● ● Last release: March 18th 2019, 0.3.6 https://vapor-ware.github.io/ksync/