The world of microservices and Kubernetes can be quite daunting — and as you scale your operation, the challenges only continue to mount. We talked to over 400 developers and DevOps engineers to identify the most pressing Kubernetes challenges. Our findings showed adoption and developer productivity were two of the biggest issues.
In this post, we'll deep dive into the numbers, the reasons
Read the full report on cloud native development workflows.→
Kubernetes challenges
Our survey of 400 developers and DevOps engineers showed that in the U.S., U.K., and Germany, including: CTOs, VPs and head of departments, director/managers and non-managerial respondents showed that Kubernetes adoption is growing.
But adoption can come with big challenges — the complexity alone can be a major deterrent. Even so, the biggest costs that we saw were associated with developer experience and productivity. We found the greatest challenges for devs in terms of:
- Time spent waiting- Respondents spend, on average, more than 15 hours every week on tasks outside of writing application code. In the US alone, this time spent could be costing companies up to $61 billion/year*.
- Slow feedback loops- All of this time spent seems to translate to frustration. 54% of respondents identify slow feedback loops during the development process as a major (top 3) frustration, second only to difficult communication between teams and functional groups (55%).
- Inefficiency- And respondents know they’re not spending their time as effectively as they could be. More than 75% of respondents say the time they spend on specific tasks is time wasted, suggesting it could be put to more strategic use.
In this post, we’ll take a closer look at the state of Kubernetes amongst our respondents: adoption, challenges, developer satisfaction, and yes, alternatives.
Kubernetes adoption
The State of Kubernetes Adoption
We asked respondents to describe their organization’s adoption of Kubernetes, and the results speak to Kubernetes’ status as a fast-maturing, widely used technology.
Only 5% of respondent organizations are not planning to use Kubernetes, and 39% are running Kubernetes partially or fully in production.
Challenges When Rolling Out To Dev Teams
And with Kubernetes adoption comes challenges when rolling out to development teams.
(Except for 5% of respondents. We tip our hats to you!)
What stood out to us is that respondents identified such a broad variety of challenges—from training, to cost visibility, to general complexity of the setup, to CI and testing—with no single challenge identified by a majority of respondents.
Which means there’s likely not one single, simple solution that would make Kubernetes easier to use for all organizations across the board. Rather, the challenges faced are likely complex and varied and require a nuanced response.
Developer productivity
Cloud native systems put more complex architectures within reach. But dev tooling hasn’t evolved in stride with that complexity. Devs struggle daily with limited environments:
- Local dev environments though fast and responsive, are too different from production to run the full suite of tests.
- CI or staging environments can run tests but can’t be used for quickly iterating on code.
Neither is a complete development environment and the differences between them are a constant source of bugs for devs and DevOps engineers. These are some of issue developers might face:
Slow feedback loops
We asked respondents to rank the top 3 things that cause them the most frustration at their job.
54% of respondents identify slow feedback loops during the development process as a major (top 3) frustration, second only to difficult communication between teams and functional groups (55%).
And “slow feedback loops during the development process” was the frustration that was most frequently ranked #1, with 20% of respondents ranking it as their top frustration.
It makes sense, once you see the sheer number of hours respondents spend on tasks like setting up and waiting for pipelines, waiting for builds and tests, and setting up development environments.
More time waiting, less time coding
Respondents spend, on average, more than 15 hours every week on tasks outside of writing application code—from maintaining internal tooling, to setting up dev environments, to debugging pipelines, to waiting for builds and test results.
The economic cost is massive—in the US alone, this time spent could be costing companies up to $61 billion/year*.
And this doesn’t even take into consideration the opportunity cost of keeping developers from higher-value work. Imagine the potential if every software developer could reclaim an extra day every week.
Something that surprised us: there’s very little variation in these hours-spent metrics even when segmenting the data by respondent department (Application Development & SWE vs. DevOps) and seniority level (CTOs, VPs and Head of Department vs. Director/Manager vs. Non-managerial).
Despite the promise of DevOps to enable greater focus and productivity for developers, respondents at all levels and across departments are spending more than a working day and a half every week on work outside of writing code.
Kubernetes Usage = More Time Spend Not Coding
First, we found that respondents whose organizations are using Kubernetes spend, on average, 2.2 hours more every week** on tasks outside of writing application code compared to respondents whose organizations aren’t yet using Kubernetes.
That might not sound like much, but it adds up to an extra 114 hours per year—more than 14 eight-hour workdays.
Specifically, respondents at organizations using Kubernetes spend, on average, 16.5 hours every week writing or maintaining internal tooling, setting up pipelines and automation, waiting for CI pipelines to run, waiting for builds and tests, or setting up dev environments.
And respondents at organizations not yet using Kubernetes spend, on average, 14.3 hours every week on those tasks.
How do respondents wish they were spending their time?
A clear majority of respondents acknowledge they’re not spending their time as effectively as they could. In fact, more than 75% of respondents say the time they spend on specific tasks is time wasted, suggesting it could be put to more strategic use.
Respondents also have a clear sense of what they’d rather be spending their time on: tasks that directly support the company’s bottom line.
- 49% of these respondents say they would develop new products and services to support the company
- 46% say they would improve speed and delivery of existing products and services
- 44% say they would improve security for existing products and services
Cloud native challenges aren't confined to Kubernetes
Also notable is the fact that respondents aren’t only using Kubernetes for container orchestration—there are many other orchestrators in the mix.
And just 3% of respondents say they’re only using Kubernetes for container orchestration.
Google’s serverless offerings have a particularly strong share amongst our respondent base, followed by those from Amazon and Microsoft.
It’s a meaningful datapoint for companies like Garden that seek to improve cloud native developer productivity.
Beyond Kubernetes, where do we need to be able to fit in with a developer’s day-to-day workflow?
And what might this distribution look like one, or two, or five years into the future?
Wrapping Up
If you have a vague (or not so vague) sense that your development team is wasting way more time than it needs to when building on Kubernetes, we’d say a) you’re probably right and b) we’re here to help.
Read the complete analysis of the challenges in the developer workflow for more info.
* Based on median pay and number of software developer jobs in 2019, as reported by the US Bureau of Labor Statistics
** “Not Using Kubernetes” respondents are those who described Kubernetes adoption at their org as “We are not planning to adopt it” or “We are trying it out/evaluating it.” “Using Kubernetes” respon- dents are those who described Kubernetes adoption at their org as “We are using it for development”, “We are partially running it in production”, or “We are fully running it in production.” These segments exclude the 5 users who responded “Don’t know” when asked to describe their org’s Kubernetes adoption.
