According to The State of Cloud Native Development report published in 2021 by SlashData, the cloud-native developer population grew to 6.8 million in Q1 2021—for a good reason. Companies like Netflix, Squarespace, Pinterest, Spotify, and many more are leveraging cloud-native technologies and Cloud Native Computing Foundations (CNCF) projects to help their organizations.
The shift to cloud-native applications and the evolution of DevOps are disrupting and reshaping the software development landscape. As technology changes, the developer experience is also evolving with it. And providing a good developer experience is crucial to the success of development teams as they adopt these new technologies.
In this post, you’ll learn:
- What cloud-native technologies are
- Some of the key benefits of cloud-native
- Best practices for optimizing the developer experience in cloud-native
Let’s dive in.
What are cloud-native technologies?
Before we dig into how to optimize the cloud-native developer experience, let’s define cloud-native and understand where it comes from.
First, here’s some background on CNCF. The Cloud Native Computing Foundation is a Linux Foundation project founded in 2015 to advance container technology. CNCF champions the cloud native movement and is dedicated to the growth and evolution of cloud technologies. The project was announced alongside Google’s open source container contribution known as Kubernetes 1.0.
CNCF hosts many different projects in the cloud native ecosystem, and once they are considered stable and in production, the projects are marked as “graduated.” Some of CNCF’s graduated projects include Kubernetes, Prometheus, Jaeger, and CoreDNS.
Given CNCF’s leadership and impact on cloud-native technologies, let’s take a look at their definition of cloud-native. CNCF defines cloud native as:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
Cloud-native development involves microservices (systems made up of small, independent services that communicate through APIs), containerization, cloud infrastructure, and the DevOps methodology. Applications and programs are considered cloud native when developed, integrated, hosted, and run on a cloud computing platform.
What are the benefits of cloud-native architecture?
There are many reasons organizations are moving to the cloud—for starters, shifting to cloud-native decreases time to market, allowing organizations to succeed and remain competitive in the rapidly changing technology environment. Cloud-native enables a faster pace because it incorporates DevOps and CI/CD methodologies, involving automation across the software process.
Another benefit of the cloud-native approach is that it makes infrastructure management effortless. With serverless platforms, there’s no need to worry about network configurations, storage, or provisioning cloud instances.
With the use of containers to manage and secure applications, alongside an open source model in terms of tooling, cloud-native architecture can help reduce costs for organizations. Containerization not only provides standardization of infrastructure, but it also helps keep costs low.
Finally, cloud-native helps teams build more reliable systems while eliminating downtime. Previously, an entire server or application failing could cause significant disruptions, making downtime feel normal and acceptable. With cloud-native, developers can isolate incidents more readily and boost uptime, thus improving user experience and customer satisfaction.
One developer’s experience moving to cloud-native
It's clear that developers also find a lot of value in the cloud-native infrastructure shift. Developer of over 15+ years and founder and CEO at Whizpool, Zeeshan Arif, told me:
“I used to work in the dark ages of mobile development. I used to go through several steps to install my app on a device: First, I'd have to build it. Then I'd have to package it into an APK file and send it off to QA, who would test it and hopefully give me feedback. Then they'd send it back, and I'd have to make some changes based on their feedback before sending it off again. Then we'd do another round of testing and fixing bugs until, finally, someone said, "Yep! You can release this thing."
That process took weeks—sometimes months—and so many things could go wrong along the way. And if you missed something during one of those rounds of testing, well…then you had a big problem on your hands when people started using your app!
But now? With cloud-native infrastructure? It's like night and day! All my apps are hosted in the cloud-native infrastructure by default (no need for extra steps), and they're tested automatically as soon as changes are made. If anything goes wrong— and it rarely does—then I'll know about it quickly and can fix it before anyone else has even noticed. And I don't have to worry about my apps being up-to-date and secure because they're always running the latest version of everything!”
Best practices for cloud-native developer experience
If you are considering or are already in the process of making the cloud-native transition, there are a few things you can do to optimize the developer experience along the way. Consider these best practices to increase the likelihood of success:
1. Define paved paths to empower developers.
At OSCON 2017, the Director of Engineering at Netflix, Dianne Marsh, presented a concept referred to as “The Paved Road,” which formalizes expectations and commitments between centralized teams and engineering customers. The philosophy highlights the importance of formalizing commitments with stakeholders, encouraging informed adventures (not accidental detours), identifying patterns across teams, and empowering innovation.
A paved path provides some standardization and responsibility while simultaneously promoting the freedom to deliver solutions within a predefined skeleton. Curating resources and providing access to knowledge, leveraging automation, and providing tools are ways to create a frame to encourage developers to work within. Consider an open source developer portal, like Spotify’s Backstage, for easy access to documentation. Paved paths aren’t a one-size-fits-all, so it’s essential to determine how to make this work best for your organization and team for effectiveness.
2. Let developers choose their tools to reduce friction.
Tooling is central to and a critical component of solid development. Throughout their careers and experiences, developers will dabble in various tools while coding. Some they’ll love and others they will hate, and the reality is that restricting tool options can be particularly frustrating for developers. For example, some developers may love GitHub, while others prefer Jenkins or Bitbucket. In some instances, developers may want to use a combination of tools to take advantage of the strengths of each one.
Instead of mandating one specific tool to use, consider giving developers a curated list of open source and low-code tooling options to choose from. Aim to strike a balance between offering various tools to choose from for flexibility purposes while keeping tool integration and avoiding lack of visibility top of mind.
Additionally, organizations should Avoid purchasing a cost-friendly tool option and expect all their developers to adopt it. And when introducing new tools to the team, remember that learning new tools takes time, and the learning curve may cause temporary friction.
3. Implement micro-feedback loops.
Tim Cochran, Technical Director for the US East Market at Thoughtworks, researches and observes technological impacts on developer effectiveness. Based on his research and experience, Cochran recommends identifying and optimizing the feedback loops developers encounter during the development process.
“From what I have observed, you have to nail the basics, the things that developers do 10, 100 or 200 times a day. I call them micro-feedback loops. This could be running a unit test while fixing a bug. It could be seeing a code change reflected in your local environment or development environments. It could be refreshing data in your environment. Developers, if empowered, will naturally optimize, but often I find the micro-feedback loops have been neglected. These loops are intentionally short, so you end up dealing with some very small time increments,” Cochran wrote.
These micro-feedback loops save developers time that they could better spend elsewhere. Watch this AWS meetup demo with Drew Khoury and Chris Hart to see this in action. Micro-feedback loops covered in the demo include unit tests, local environment, end-to-end tests, direct deployment to AWS, and CI/CD runs the same as local. (Read more: Optimizing DevOps feedback loops in software development)
4. Always start small before scaling.
Code and infrastructure changes simply won’t happen overnight. As many organizations start to move toward a cloud-native approach, it’s essential to be intentional and roll out changes over time. Too many changes all at once can overwhelm developers and leave them feeling like they have no control over their day-to-day responsibilities.
It never hurts to review your current processes and workflows and reevaluate and improve those first rather than making changes that might feel like the right ones without knowing for sure. Providing a great developer experience requires understanding your team and supporting them in the ways that work best for them. (Need tips for improving your overall developer experience? Read more: What Makes for Good Developer Experience?)
5. Measure developer experience (DX) and adjust accordingly.
It’s not enough to implement a few best practices and hope for the best. To optimize the cloud-native developer experience over time, ensure you measure and monitor DX throughout the process, so you know where to improve. Consider metrics like findability, usability, and credibility, as well as how supported your developers feel when working in the cloud-native environment. Understand where your developers are experiencing pain points and try different solutions to continue to improve the developer experience over time.
Going forward
If there’s one thing for sure, technology is constantly changing and evolving—including the cloud-native environment. More organizations are leveraging cloud-native technologies, and this shift is reshaping the software development landscape. Applications and programs are considered cloud native when they are developed, integrated, hosted, and run on a cloud computing platform. Benefits of cloud-native include increased time to market, effortless infrastructure management, and reduced costs. Best practices for optimizing cloud-native developer experience include defining paved paths in the ecosystem, providing tooling options, implementing micro-feedback loops, starting small, and measuring and pivoting along the way.
Check out these resources to continue your learning:
- Episode 89 of The Secure Developer: Containers and Developer Experience in the Cloud Native World with Justin Cormack, CTO at Docker
- Episode 101 of the Code[ish] podcast: Cloud Native Applications hosted by Joe Kutner, with guest Cornelia Davis
- The Phoenix Project by Gene Kim
About the author
Alyssa Towns is a freelance writer for Clockwise based in Denver, CO. She works in communications and change management. She primarily writes productivity and career-adjacent content and has bylines in G2, The Everygirl, Insider, and other publications. When she isn't writing, Alyssa enjoys trying new restaurants with her husband, playing with her Bengal cats, adventuring outdoors, or reading a book from her TBR list.
