- Home
- >
- Software Development
- >
- The Human-Kubernetes Maturity Curve – InApps 2022
The Human-Kubernetes Maturity Curve – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn The Human-Kubernetes Maturity Curve – InApps in today’s post !
Read more about The Human-Kubernetes Maturity Curve – InApps at Wikipedia
You can find content about The Human-Kubernetes Maturity Curve – InApps from the Wikipedia website
This is part three of a three-part series. Here are parts one and two.
Daniel Bryant
Daniel is the director of developer relations at Ambassador Labs (formerly Datawire). Daniel is a Java Champion, a TechBeacon DevOps 100 Influencer and he contributes to several open source projects.
If asked, it would seem a logical answer for many people to say that once they’d adopted Kubernetes, they’d already done the hard work of going cloud native. They’ve put themselves on the path to cloud native development and are off to the races. Maybe they have considered and reduced the inherent complexity of the cloud native developer experience and matched the technology to their business goals. But it’s also possible that one critical, and arguably the most important, component isn’t accounted for: the human aspect.
In parts one and two of this three-part article series, I discussed how developer control platforms emerged as a way to “tame the cloud,” provide productivity-supporting abstractions for developers and support business goals. But no platform can succeed if the developer doesn’t bring their human sensibilities to development. By extension, our panel of cloud native experts argued that the better developer, and developer experience, stems from the human element — empathy, understanding and being part of a community.
Empathy for the Daily Reality of the 99%
The sometimes-buzzy nature of cloud native eclipses the daily reality for the vast majority of developers. Many developers (the “99%”) are entrenched in building software for critical use cases and cannot easily move from legacy platforms and tools. For a number of reasons, from stability to compliance to data privacy protection, they can’t discard what works well in production and best serves the end users’ needs without considerable deliberation and justification. After all, not every organization is a FAANG — acronym used in reference to the five tech companies Facebook, Amazon, Apple, Netflix and Alphabet (Google) — nor should they aspire to be.
That said, it is also important to note that just because cloud native development happens to have the buzz du jour, it doesn’t mean that it isn’t realistic or possible for the 99% to adopt in one way or another. Many companies of all types and sizes, for example Zipcar and Veterans United Home Loans, have introduced cloud native development to their mission-critical work.
In the end, it is about what works for the organization and its use cases, what is comfortable for the organization and its developers, and ensuring the best possible end-user experience. Understanding and accepting that not every organization needs Kubernetes or microservices architectures requires a baseline of empathy for the developer in whatever circumstances they work.
Developing Mechanical Sympathy
“Understanding” is a keyword in the development sphere overall but particularly in the human-Kubernetes maturity curve. First, in understanding that cloud native development isn’t right for everyone. Second, in arming cloud native developers with the relevant knowledge they need to understand the big picture without necessarily having to act on it.
“Mechanical sympathy,” a term attributed to Martin Thompson, applies in this context: The better a developer understands the hardware, infrastructure and how things run, regardless of whether they have to ship and run the software they code, the better they will be at coding and avoiding problems down the line.
As CEO/CTO of OpenCredo, Nicki Watt, explained, “Perhaps more important than actually being empowered to, and tasked with, running software end to end is understanding. That is, developers should possess multiple skills and understand exactly what they’re working on, even if they are not responsible for running it… In many organizations, empowering developers with in-depth knowledge about how distributed applications work and the common challenges inherent in distributed systems provide more value to both the organization and the entire team (the developer, the SRE, the ops teams, etc.)”
Being More Human
Underpinning understanding goes beyond just mechanical sympathy and understanding how things work mechanically.
It is, as Google’s Kelsey Hightower shared, deeply human, “If you get really good at the human side of it, I think you will end up writing much better software.”
Hightower highlighted what he calls “empathetic engineering,” meaning that at a high level, engineers need to use their own product to understand what the experience is like for a user and make it more reliable. What will the user do with this software, and if they cannot get it to do what they want — achieve a specific goal or task — the software needs to change.
The fastest, most direct way to embed empathy into software development is to get comfortable viewing things from a human lens, digging into customer service and user experience, including predevelopment research and peer review.
As Hightower said, “There was a time when you could get pretty far as a developer without ever using your own product, but it does not work anymore. Once you’ve experienced an application that makes you think, ‘Wow, someone thought about how I would use this when they created it; it’s intuitive, it’s frictionless,’ you start to see the difference between end-to-end empathetic engineering and the kind of development that feels like no one tried it out at any point in development.”
Participating in the Kubernetes Community
Once you extend beyond technology and tooling and into individual empathy and humanity, the maturity curve reaches new heights when the Kubernetes community is considered. The community drives and defines cloud native, and the deepest understanding of all, according to members of the community, comes from connecting with others within it.
Katie Gamanji, former ecosystem advocate at the Cloud Native Computing Foundation, explained, “Anyone who’s trying to understand what cloud native is and what to make out of it… you can get your answers in the community. Once you are in this space, I think it’s very important to get to know your folks, the maintainers of the projects you’re using, or even become one of the contributors. The community is there; try to reach out. Technology is great, but the community around cloud native, it’s what really makes it great.”
Summary: The Human-Kubernetes Maturity Curve
Developers and the end users they develop for are human. Ignoring or neglecting the humanity behind the code stunts the success and maturity of an organization. Cloud native leaders across roles concur that developers (and their end products) benefit from actually talking to users before coding.
In the same way that developers are not interested in using developer platforms on which they have not been consulted, end users won’t respond favorably to applications that don’t consider their needs.
Introducing listening, empathy and communication of the developer experience is a true sign of human-Kubernetes maturity.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Hightower, Ambassador Labs.
Photo by Dan Meyers on Unsplash
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.