Okteto: Need for developer tooling

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:

1. configure okteto to connect to your cluster
2. git clone <your repo>
3. 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