Your development workflow is the process by which your organization develops software. A typical development workflow starts with product definition, and then moves through development, testing, release, and production stages.
The stability vs velocity tradeoff
Organizations tune this workflow for their given business needs and application. Typically, this involves optimizing the workflow to provide the right balance of stability versus velocity. As the application becomes more popular, insuring that updates don't negatively impact users becomes more important. More stringent release criteria, better testing, and development reviews are typical strategies that improve stability. Yet these strategies aren't free, as they reduce velocity.
(Haven't you ever said "we used to ship software so much faster, and now it's slowed down even though we have twice as many engineers?")
Scaling your development workflow
The problem with the development workflow is that no amount of optimization can overcome the fact that there is no single development workflow that works for every part of the application.
The reality is that some parts of your application demand stability, while other parts of your application require velocity. What you really need is multiple workflows that work for different parts of your application.
Microservices
Microservices is distributed development workflow, enabled by splitting your application up into smaller services. By splitting your application into smaller components, you're able to run independent development workflows for each of your services.
You want to run a prototyping workflow for early feature development. As your service matures, you'll want a workflow that supports rapid updates in production. And as it becomes a mission critical service that other services or users really depend on, you'll need a workflow that insures rock-solid stability.
Building a workflow is both easy and hard
The challenge of building a microservices workflow is that you need a standard set of tools and processes that support all these different modes of development. You don't want one set of tools for prototyping, and another set of tools and workflow for production.
In addition, a microservices architecture, the development teams are typically responsible for a service and not just the code. This implies that the development teams need operational skills and capabilities, e.g., monitoring and deployment.
Luckily, Kubernetes has become a de facto standard for running cloud native applications. The Kubernetes ecosystem provides a robust set of operational infrastructure with which to run microservices. So you don't need to start from scratch.
Open Source Tools
The following open source tools may be helpful for optimizing your development workflow on Kubernetes:
What do you think?
What does your development workflow look like? What tools do your developers use, and what pain points do they face?
Top comments (5)
Hey Kelsey, good read. I just started with kubernetes and was just reaching the point where I asked myself how I can get a fluent dev workflow with it. It seems to be that, without significant effort, the workflow is "Push to production to run your code changes", which is, well, not optimal :-) I'll check out your links!
We're starting to work with minikube for local k8s. This might be what you're looking for. I get to document it as it's new to our dev workflow, so maybe I'll do a blog post about it in the near future.
Even with minikube, you have steps to push your local changes into the kube that take long and are hard to maintain. Think of the steps you have to take between saving you code in the editor until you see it live in your browser.
Minikube works except at some point you might end up where you have too many services to run locally (think if you need a database, and ElasticSearch, and few Java-based services). Your laptop will melt down.
Also you still need ways to deploy multiple services with a single command into minikube, etc.
I'm new to k8s, so thanks for that feedback Richard. Much appreciated.