Okteto: Need for developer tooling

#kubernetes #okteto #dx

In the early days (read precursor to containerization) development cycle was straight forward. You code with an editor, compile, build, run and test and are done. Deployment would be some version of copying to another device and setting come configuration.
The game changed with the advent of docker. One sets up a development host (often local machine) and uses some orchestration (aka docker-compose) to run locally qualify(unit-test) and push. CI environment is another world where configurations are re-applied an integration scenario is tested and given a go-ahead. Production is of-course the real place where hammer meets the iron and battle rages on ...

Developing this way is painful due to:

multiple tools that need be used for each environment (eg: docker-compose on DEV, kubernetes on PROD)
maintaining configuration parity across environments
managing configuration drifts from cluster to code
local development is a resource hog (in terms of cpu and battery; the process qemu-system-aarch64 was constantly taking >98% of my resources)

Expectations from a cloud-native DX:

should be fast
change reflection should be seamless (think live-preview)
configuration overhead should be minimal
simple flow - installation/setup, creating, tweaking and destroying environments should be easy

Okteto accelerates the development workflow of Kubernetes applications. You write your code locally and okteto detects the changes and instantly updates your Kubernetes applications.

Typical workflow with okteto is:

configure okteto to connect to your cluster
git clone <your repo>
okteto up that helps you seamlessly deploy and synchronize apps to the cluster with:
- bi-directional synchronization service through configuration
- automatic local and remote port-forwarding for connecting through localhost and for attaching debuggers
- interactive terminal for build-deploy-test cycles

workflow, configuration and other details will follow in next posts of the series