Tight Inner Loop Development

This past week was KubeCon 2020 North America and there were many wonderful talks given covering every possible avenue of this industry. As usual, I am focused on crafting an exception developer experience on top of Kubernetes and I am appreciative for the wise words of Thomas Rampelberg and Daniel Bryant. I asked Thomas for specific advice about the Kubernetes journey and he shared that it will take longer than anyone expects, the training of the teams involved is key to the adoption, and small incremental steps pave the way to broader adoption.

It’s been nearly five months since the start of this journey and my alpha version of my product is now available. We are abstracting away a significant amount of the experience from the developers which is beneficial for them to learn less. However, I realize that my options for training are significantly limited. The training on the market is geared toward people working with kubectl directly or learning YAML configuration. My hope is that by onboarding a real project I have time and experience to work with fresh people and shape a curriculum around working with this new fresh framework. While they should not have to know everything about Kubernetes it will be helpful to know when to pull away the curtain of abstraction and look at how the machinery works. I am optimistic by creating enough hand-crafted educational videos and explaining how inner-loop development works that I can demonstrate the value of the adoption.

Inner Loop Development

At this moment I believe that the Okteto CLI provides the most seamless experience for inner loop software development. On any journey being first does not constitute safety or success. I continue to mull over the benefits of Bridge to Kubernetes versus Okteto. At this time I believe that Okteto provides a superior experience by moving the development experience into the Kubernetes cluster. I feel like for many reasons this is beneficial because I already depend on many facets of a deployment that I cannot set up locally without significant work. Secrets, Kerberos sidecar, and other details.

What does inner loop development look like or being first is pretty rocky

This past Friday my colleague and I walked a developer through the process of setting up a new application for inner loop development. This was helpful for me to remember and walk through all the steps it takes for a new .NET C# Windows Desktop Software Engineer to be productive.

  1. Visit the portal and generate a new API project
  2. Clone down the project
  3. Open the project in VSCode
  4. Log in to Rancher to download the development environment kubeconfig and create a new file named config in C:\Users\FirstName.LastName.kube
  5. Download the Okteto CLI and add it to your system PATH
  6. Open a terminal in VSCode and “okteto up”
  7. Generate an okteto.yml file and answer the prompts
  8. Update okteto.yml to point to the namespace of the project and make sure the name matches the .NET csproj which for us should be equal
  9. Change the default port from 5000 to anything else because something in the enterprise already runs on that
  10. okteto up again and you should be plopped into a bash terminal able to run your project
  11. cd src/myprojectname/ and run dotnet watch run
  12. Debug the project using a configuration similar to the one here we had to change the path of the sourceFileMap to /src/app/src/ because of how we make projects
  13. Update pipeArgs to match the project name from the okteto.yml file ex: mynewproject.okteto
  14. Set a breakpoint and hit a route and we are in business to debug our application

Windows Pain Points

For a person used to living in Windows land software development, there are a lot of hurdles to jump through. A lot of these patterns and behaviors are outside the realm of typical .NET Framework development but a little closer to what .NET Core offers. The .kube hidden folder is a bit of an annoyance and while we avoided asking the developer to install kubectl there isn’t anything stopping that from happening for good or bad. Okteto is a great experience but asking a Windows Developer to update their PATH is a bit of a challenge. I hope there could be a user-friendlier experience where the path can be updated automatically using some installation MSI or other solution.

I have no clue if the majority of developers feel comfortable on the command-line but for this user they had Powershell as their default VSCode terminal. This resulted in garbled output once Okteto started running and we found a temporary command to enable virtual terminal sequences. I am proposing to Okteto to detect if virtual terminal sequences are supported and if so enable it for Powershell users as they run the command. Ideally, I do not want users having to flip this on system-wide at all. Another challenge I ran into is the omnisharp extension in VSCode where using the Windows 10 provided OpenSSH client hangs instead of listing the processes available in the remote client available to attach to. I proposed to omnisharp to add an explicit exit as part of the bash command so it does not hang.

Once those challenges are overcome I am highly encouraged about the inner loop development experience that is offered. Currently, Bridge to Kubernetes feels like it is for people that expect more access to the underlying Kubernetes. I am not a fan of the administrative prompts triggered by the “Endpoint Manager” before connecting to the remote cluster. Much could change in the future and for now, I think Okteto offers the best way to limit the complexity of working with a remote Kubernetes cluster.

Okteto Up Experience

Once okteto up starts you are now in the prompt of your container with your code sitting there. You can start it with something like dotnet watch or you can update the command to start from that experience. You will have all the resources you are accustomed to running directly in the cluster. This removes all the overhead of thinking about, “how do I access my secrets?”, “how do I authenticate to my MSSQL database using a local Kerberos sidecar?”. Those questions are gone. Instead, you are faced with your application running in an environment where you can quickly and easily iterate on new functionality. You are not bound by the fast but not fast enough CICD experience that requires waiting for processes to kickoff and complete before a new container is deployed to a cluster.

Looking forward I could see many avenues to make this experience even easier. I’m appreciative the golang ecosystem enables great cross-platform interoperability. In the past, it seemed like a product could only ever be Linux, or Mac, or Windows and now it seems like bridging this chasm is less challenging. I think my biggest challenge will be continually trying to connect with software engineers not exposed to this Kubernetes world and attempting to teach the concepts that are important to know and remove the details that are not important at all.

I invite you to try the Okteto experience. While you may not be in a .NET windows shop like me you can benefit greatly from this style of software development.