Prologue

A common mistake that I deal with as a platform developer is exposing too much of the internal workings to users. Most platform teams provide some pre-configured auxiliary tooling (version control, secret and configuration management, logging and monitoring, etc.), but when it comes to deploying the actual workload and its dependencies — quite often, each team just gets an isolated sandbox (e.g. k8s namespace, AWS or OpenStack project) with pre-configured quotas and a carte blanche to do whatever they want with it.

To some people, this approach might seem like a reasonable separation of concerns. After all, isn’t this what DevOps is about: developers getting involved in the operational side of things? Since they have all the necessary tools to get their applications up and running, can’t we just wash our hands of the whole thing and focus on something else?

Not quite. While such degree of freedom might be appealing both to you as the platform owner and to some of your users, it inherently comes with an issue that, when left unaddressed, will eventually create a huge mess.

Why self-service alone isn’t enough

The problem here is that working with raw virtual infrastructure (virtual machines, k8s manifests, etc.) forces users into making dozens of decisions, for most of which they lack contextual knowledge and/or professional expertise.

Imagine developing a huge service containing numerous modules depending on several databases and other services. Such pieces of work can easily span multiple sprints and involve writing thousands of lines of code. And then, each single deployment of your app would also require you to figure out how to deploy its dependencies. How do you create, store, and access a service account for the database? How do you collect and where do you store its backups? How do you configure replication and failover?

Most of these questions do not just require in-depth understanding of system administration: they also require a person to know the bigger picture. To get a definite answer on any of these, you would need to know how things are handled in your particular organization: which storage and configuration options exist, what the security policies are, which limitations the virtual infrastructure imposes, and the list goes on. In other words, they would need to know everything that you, the infrastructure owner, is supposed to know.

What do real people do when faced with such decisions? They offload them. Long configuration files get copied and pasted mindlessly and then tweaked chaotically until something resembling a working solution arises. Even if the person in question is highly qualified and actually knows their way around, there is a high chance of them producing something non-standard and, thus, poorly maintainable. Once the need arises (and trust me, it will) propagate some change like a security patch among all the teams using your platform, you’ll most likely find yourself in a position where you have to manually browse through hundreds of similar-but-not-quite-identical installations and figure out how to actually do it without downtime.

By giving the users the (almost-)infinite possibilities of working with raw manifests, you both waste their time on learning the infrastructure context they don’t necessarily need and your own time on dealing with the spectrum of your users’ inventions.

What you should be doing next

Sadly, as platform builders, we sometimes lack the mindset that most (good) product teams have: focusing on users. While the need for dedicated people handling user stories and customer relations is almost self-evident in teams dealing with external clients, internal (our platforms’) clients quite often get much less attention. Doesn’t mean they need it less! What I encourage you to do is to go beyond the ticketing system and reach out to actual people using your platform.

Luckily, there is a plethora of ways that you can collect feedback from users: surveys, interviews, shadowing, live demos, and what not else. Just pick any single one that you find suitable for your situation (ask a product owner colleague of yours when in doubt) and start performing it at regular intervals, say, quarterly. The key points to look at are:

  • which parts of your platform do your users most interact with and which are underutilized;
  • how straightforward the user flow is then dealing with specific scenarios (e.g initializing and deploying a new app, collecting telemetry, etc.);

A scenario that is neglected by users is quite often an indicator of poor user experience and would likely require you to either rework an existing abstraction layer or create a new one (e.g. a new API method, library, k8s operator, frontend app, and so on). Think of the excessive decisions or actions the user needs to make during doing their job, and come up with a way to make those decisions for them.

Quite often there will be no straightforward way to do this: say, your company might have a convoluted user directory with multiple sources of employee data without a single interface, a highly-segmented network requiring constant firewall rule updates, a weird security policy forcing really short login sessions, etc. While being painful to deal with, such problems give you precious opportunities to drastically improve user experience and build political capital that would eventually help you implement even bigger projects. Just be inquisitive and assertive: I can’t stress enough how important it is to reach out to people and ask them why the things work the very specific way they do, and whether anything can be done about it. You’d be surprised how forthcoming people can be, and how many low-hanging fruits there are: sometimes, a single small configuration change done by another team can make all the difference to the quality of your own product.

Epilogue

To everyone who needs to hear this: it is time to get your head out of the shell and actually reach out to people. A functioning self-service platform is a good start, but once the very basic technical stuff is done, you need to be proactively looking for friction points. Focus on the biggest ones and don’t spare any effort eliminating them: this is the work that will actually pay off for both you and your users.