Kubernetes Development Tools
Why Thunkable is excited about trying them out!
Thunkable enables anyone to create beautiful and powerful mobile apps. This is the first post(of what we hope will be many) from our engineering team.
What are they?
At their most basic level Kubernetes development tools extend the fast feedback loop you’ve come to expect from application development tools such as Create React App and Nodemon to your infrastructure development workflow.
But, their true power lies in the fact that Kubernetes (K8s) is a container orchestration tool. What’s inside these containers? Your application and its dependencies. Therefore, K8s dev tools orchestrate the development, testing and deployment of your application, its dependencies and its infrastructure.
What problems will they help solve at Thunkable?
At Thunkable we rely on Docker and K8s to build and deploy new releases to production. This is made possible by the combination of our Dockerfile’s instructions for how to build an image of our application and our deployment.yaml’s description of how the containers running our application’s image should be configured. Contrast this with our current development environment in which each developer must ensure that they have the correct versions of all our dependencies installed and properly configured by faithfully following all the steps in our various READMEs.
The goal of K8s dev tools is that we can share the benefits we obtained with Docker and K8s in production with development.
This summer we had a plethora of interns and getting their development environments setup brought on flashbacks to earlier days when we used to manually build and deploy production to multiple machines in much the same way … with more trial and error than we care to admit. Once you have a dozen developers, sending out a message telling them all to update Node.js, npm or Ruby to a particular version right now becomes untenable.
Did you try running
npm installin the frontend package? What about the backend? the app? Maybe it’s a native dependency. Did you rebuild the iOS app?and Android too? Not working? Did you forget to runpod install? Still not working? Rungit clean -dfxand try everything again … from scratch.
On top of that, when developers switch between branches dependencies aren’t automatically resolved leading to huge time sucks. It’s a universal truth that the longer one developer is struggling to get a branch running the more nearby developers get pulled into the fray. K8s dev tools aim to solve this problem.
Why is Thunkable looking at them now?
I’ll admit, it’s early days for K8s dev tools. They have lofty road maps ahead of them to reach v1.0.0. Running K8s locally on your laptop eats your battery while running K8s remotely requires a fast reliable internet connection. But with Google, Microsoft and a couple of startups (plus some more that I’ve surely missed) in the mix progress will happen very fast. It’s not a matter of if these new dev tools will become the new standard, but when.
Who are they?
If you already have your continuous integration and continuous delivery (CI/CD) pipeline up and running then you likely have some breathing room to let these tools mature, but if you’re just starting down this path these tools are worth careful consideration. At Thunkable we’re at the point where we need to put some work into our infrastructure in order to support CI/CD. Even if we find these K8s dev tools aren’t ready to drive our application’s development they’ll provide a fast feedback loop to allow us to more quickly implement and test additions and improvements to our infrastructure code.
What’s next?
Do you have any tips for us as we explore these tools? Please save us some time by letting us know! For my part, I’ll be sure to write a follow up blog post about our experience trying out these tools.
But wait! Which one should I try?
Sorry to disappoint this isn’t a “Draft vs Garden vs Skaffold vs Tilt” post. But, I’ll be sure to share which one we end up using in my next blog post. The good news is that a lot of the underlying support you need to implement in order to take advantage of these tools is just plain old Kubernetes YAML and Dockerfiles. Thus the effort to switch between them should be significantly lower than the initial cost to implement any of them.
