CWDN series: Dev-eXperience - Venafi: The key to good DevEx? Cut the yak shaving
This is a guest post for the Computer Weekly Developer Network written by Matt Barker in his role as president of cloud native solutions at Venafi and Steve Judd, chief solutions architect at Venafi.
Venafi helps enterprises take charge of their machine identities, both on-premises and in the cloud, with centralised, controlled management to deliver observability, consistency and control.
Barker & Judd write in full as follows…
Developer experience has long been characterised by ‘yak shaving’ – the perennial problem of endless small tasks that must be completed before the next step in a project can proceed. Since computers were first invented, companies have attempted to reduce this burden by creating self-service tools.
NOTE: TechTarget defines yak shaving as follows: The term yak shaving caught on. It refers to engaging in a meaningless task that has no obvious relationship to what’s supposed to be worked on but may be necessary to troubleshoot a larger problem. The process of making a simple task unnecessarily complicated may also qualify as yak shaving.
In the era of cloud-native development, we are seeing the emergence of self-service platforms, where developers can request cloud infrastructure so they don’t have to build and configure it themselves i.e. less yak shaving, right?
With today’s need to develop faster and drive cost efficiencies, there is a focus on how self-service tools can improve the developer experience and accelerate innovation. But there’s an ongoing challenge in encouraging developers to actually use self-service tools, rather than let them sit on the shelf.
Consistency is key
The move to cloud has put a spotlight on consistency issues. Developers can pick from a huge range of services, so teams end up using a number of different tools and configurations across multiple cloud infrastructures and providers. For example, some teams might use Kubernetes or Lambda functions, while others might prefer Cloud Run.
This lack of standardisation makes it difficult for developers to move between teams, as they have to spend time being onboarded and learning how to use a new set of tools. There’s also no benefits of scale and shared knowledge across the organisation. Teams can’t collaborate on the best way of approaching development, because they might be the only ones using a specific technology.
This approach is costly.
Developers have a bad habit of leaving expensive services running when they no longer need them – racking up unnecessary bills and frustrating finance teams.
In comes self-service. By providing a vending machine of approved products that developers can choose from, organisations can ensure developers are using standardised templates and services. For example, if a developer wants to run a container, the self-service tool can provide two options – Kubernetes or Cloud Run – both of which are in a template.
Consistency also encourages collaboration and communication between teams. Infrastructure and security teams can keep tabs on the products used and for how long, and know that every tool complies with the organisation’s governance.
Time is money
Developers need to build new products and services faster than ever. But cloud-native development is complex and mastering it takes time that many developers do not have.
Self-service tools provide reusable templates that increase development speed. For instance, if a developer knows a template for provisioning a Google Kubernetes Engine (GKE) exists, they can find the relevant template in the service catalogue and add in the customer parameters. They will automatically get a GKE environment that meets organisational guidelines without doing any of the heavy lifting.
This saves developers from having to learn the intricacies of IT infrastructure and spend more time coding instead.
Creating repeatable environments
Self-service tools are going even further in the production of repeatable developer environments, like the Development Container Initiative. These environments provide developers with a container that has everything they could possibly need, within the governance specifications of their organisation. Developers can run products and services in these containers, rather than having a list of things to install before even getting started on the project.
For example, consider a developer using VS code. Rather than having to install VS Code then a list of standard plugins, they get a developer image for VS Code with plugins already installed. This means that no matter what team the developer is in, the experience and the tools they use will be exactly the same.
Self-service tools as products
With the right approach, there is huge potential for self-service tools to enable a better developer experience. One common mistake is that self-service tools aren’t designed with developer pain points in mind.
Platform Engineering Teams must treat self-service tools as a genuine exercise in product development. Their client base is internal users, so they must sit with developers and discuss what features they need. For example, by asking what is stopping developers from increasing the number of story points they can get through in a sprint. They will get a long list of issues and can tackle the high priority ones first.
It’s important to remember that it might not be one self-service tool that fixes the developer experience, but a multitude of tools and options that cater for how the individual or team works. Developers need multiple options that can do the same thing but are suited to the workflows of different types of developers.
If self-service tools and the resulting platform isn’t managed as a new product development exercise, organisations risk not getting developer buy-in and making the problem of developer experience worse. However, by taking the right approach, self-service platforms have the power to significantly improve the developer experience.
Free image use: Wikipedia