Table of Contents
This is part four of our five-part series exploring cloud-native technologies. In part one and part two you were introduced to a cloud-native system and learned more about the ins and outs of establishing your cloud-native infrastructure. In part three, you took a look at the initial distribution process and rollout and how you can reduce friction.
Successfully navigating cloud-native technologies means getting your engineers, or your system’s internal users, onboarded and involved. Ensuring that your cloud-native setup is enjoyable to use is key to achieving that.
This article discusses why and how you can optimize your infrastructure’s user experience (UX) to better serve your DevOps professionals.
What Is the Developer Experience?
At its simplest, the developer experience (DX) in the cloud-native system is an extension of UX during periods of infrastructure management (in this unique case). It encompasses any essential tasks and daily workflows that a DevOps professional may encounter.
Before we dive into the nuances of DX, let’s first consider the conventional notion of UX. Good companies create a positive UX across products and services, and that effort keeps users coming back. Conversely, poor UX drives users away. Clunky interactions, unnecessary complexity, poor performance, and limited functionality are some of the many things that can cause friction and result in unsatisfactory UX.
That said, there’s often a false dichotomy of good UX versus bad. Since no application is perfect and pleasing everyone is impossible, the truth is that users often accept elements of both. However, companies should be incentivized to develop the best UX possible with research and feedback compilation.
Creating exceptional experiences for developers and engineers is a little trickier. DX is the umbrella term adopted due to the complexity of DevOps roles. Professionals use a vast array of toolsets to navigate their workflows and they regularly grapple with sensitive administrative tasks. Each also brings a unique skillset to the table that then impacts their level of comfort with specific technologies and processes.
In addition, DevOps culture is becoming more ubiquitous across the industry, but development teams still have varying levels of pull within their organizations, which casts doubt over whether their opinions are really being heard and respected.
With all the above in mind, you can see that DX is about more than just one internal application. It describes the everyday developer processes and interactions that (hopefully) streamline development, programming, and administration. Forging great DX takes time and attention.
Your goal should be to make your DevOps professionals’ lives as easy as possible. In fact, developer buy-in and productivity tie directly to DX. Below, you’ll find guidance on how to empower your teams to perform well.
Optimize for Developer Experience (DX)
DX is critical for developers, and including this group in discussions and planning is essential. This seems like an obvious point; however, many decisions have historically been made by those who think they know what’s best for developers, or who favor rigid approaches, as opposed to those on the “front lines.” It’s impossible to create a developer-centric software architecture without understanding how developers themselves will navigate it.
The design phase entails crafting the backend and frontend of your infrastructure. This includes the key pieces that help it run, maintenance pathways, and any documentation supporting these elements. Blueprinting and considering the technical viability of your infrastructural design will ensure that developers can properly operate it. Architectural oversights can turn into major obstacles, and you don’t want to blindside your team with a design they’ll struggle to handle.
Keeping developers engaged throughout the design process means that underlying mechanisms will work for them, not against them. From brainstorming to implementation, making DevOps voices heard will boost satisfaction and long-term usability. This guarantees that your developers’ top needs are met and that infrastructure will provide value to those closest to it.
Ditch Tooling Mandates
Proper tooling is central to knocking out core development tasks like coding and configuration management. Team members will, as a result, be exposed to a variety of programs, and these experiences will dictate their preferences. While developers are likely to have never encountered a tool they absolutely love, there’s a good chance they’ve used something they simply can’t stand.
Tooling mandates stem from many places. In a typical scenario, Company A has a contract with Company B, perhaps a SaaS, PaaS, or IaaS provider, that grants them access to productivity software. The customer might be obligated to use a specific tool (or tools) that will lead an organization to spend time and money to secure tooling rights (if they haven’t already done so in the past). It’s simply “the way things have always been done” for many companies, even as numerous developers have come and gone. Additionally, companies might aggressively promote common tools to reduce fragmentation.
It’s easy to see how this can quickly become problematic in a multi-cloud context. Companies love leveraging multiple cloud providers to avoid lock-in, while still offering them granular control over functionality. As a result, implementation strategies have become increasingly piecemeal by design.
Why can’t developers enjoy those same privileges? After all, more and more tools are becoming vendor agnostic, meaning they support a number of underlying technologies. These diverse integrations fuel productivity.
Data suggests that tooling flexibility is advantageous. For example, the top companies use thirty-seven different tools or software platforms on a daily basis, while large companies use upwards of ninety. Specialization has become the new norm, and that open-minded approach to software must trickle down to DevOps teams. There’s a good reason why the third-party tooling market is so saturated: people love and need options.
A key point to keep in mind is that you should let the developers choose the tools so as to reduce friction. For example, don’t mandate Bitbucket when your team only has experience with GitHub. Allow developers to use Sublime Text instead of Visual Studio Code or Codespaces, if they wish. Don’t fall into the trap of making exclusively budget-focused decisions on tooling, because the negative ramifications can be much costlier.
Another point to keep in mind is that learning new tools takes time and you should go into the process knowing that productivity will likely suffer for a period.
It’s also entirely possible that one tool executes a core workflow or automation objectively worse than another. Level of comfort and development needs should drive these choices. It may even be best to let teams build their own customized tools, assuming they have the bandwidth to do so.
In some cases, your employees might not know which options are ideal for them. Providing a list of tooling recommendations is a helpful gesture. At worst, curating a list of “supported tooling” can offer guidance to undecided professionals.
Share the Keys to Kubernetes Clusters
Containerized applications are all the rage, and Kubernetes orchestration has become central to roughly fifty percent of organizations. Key development workloads and applications run within the Kubernetes cluster, and this is where you’ll find the components that power your virtual backend. Accordingly, resource, configuration, and permissions management are crucial to getting the most from your deployment.
Leaders should delegate these administrative tasks to developers and engineers who have the proper authorization and cluster access needed to make changes. This helps teams respond to outages and remediate other issues. Concepts like GitOps—sets of DevOps best practices governing collaboration, compliance, CI/CD, and version control—enable automation, saving developers massive amounts of time and effort.
How do you delegate cluster access? Using a GitOps tool like Argo CD can be immensely helpful. Authorized users can leverage an API, a repository service, and a Kubernetes application controller to complete a number of tasks:
Features like these are designed to streamline processes that would otherwise be tedious or technologically complex. Argo CD and tools like it help developers be more productive using methods analogous to processes they’re already regularly using .
Additionally, platforms like DevSpace are geared toward developing and deploying Kubernetes apps. A cloud-native approach like DevSpace that’s built for modern ecosystems has a strong following because it provides all-encompassing automation, real-time container updates mid-coding, a functional UI, and cross-environmental unity. These features were all developed to prevent headaches, while also helping teams collaborate.
Feedback Is King
The DevOps pipeline is now central to the DevOps experience, in part because it promotes continuous improvement. The feedback loop mechanism ensures that development and production issues are uncovered. From there, the party responsible for making changes can do so, shipping out fixes as needed.
Feedback is important both from a coding standpoint and systemically. When considering architectural design, including tooling and processes, teams must always seek ways to improve, especially as problems might not always be apparent to leadership. Developers and engineers in the proverbial trenches have the ability to evaluate their environments more closely. Accordingly, they can provide valuable feedback on how the system is working. You can harness that information and make improvements; your teams will thank you, and they’ll feel more involved.
Start Small and Scale Up
Lastly, when implementing any code or infrastructure changes, take a thoughtful approach. Create a proof of concept as a first step. If you start by ensuring viability and scaling slowly, your DevOps pros will encounter fewer surprises. Handling complex projects in stages can contribute to preventing developers from feeling overwhelmed.
This is also where culture comes into play. While ownership and accountability are important, fostering a blame-free environment can boost morale. Developers ultimately want to deliver a quality product (even if it’s an MVP), and thus understanding their limitations can temper expectations. That’s how quality software is shipped. In short, letting developers operate realistically within their resource constraints will make everyone happier.
Conclusion
Building sound developer experience isn’t necessarily easy, nor is it an overnight endeavor. However, the benefits to productivity and morale cannot be overstated.
From tooling to culture, there are many ways in which you can empower your developers to do their best work. It requires an open mind, and maybe even some yielding of control at the leadership level. However, your organization and teams will ultimately be much better off for it.
Photo by CHUTTERSNAP on Unsplash
