Designing Developer Friendly Self-Service Platforms

Imagine that you're a DevOps developer.

Everyone keeps asking you to do something.

"Hey, can you help me deploy this?"

"Hey, something broke in production and I have  to roll back, can you help me do that?"

"Hey, can you set up monitoring on my project?"

The usual response would be to automate all this but sometimes automation is not enough.

We need something more.

What if we want to release an old version of an app with a click of a button?

What about setting up configs for gathering metrics using YAML schemas?

Well, this is all possible with self-service platforms.

Self-service platforms are software tools that allow people to manage their business processes.

But the ones we will talk about today focus on the developers. All with the common goal of:

How can we empower developers and make them more productive?

Examples of these tools include:

• AWS for cloud computing services.
• Kubernetes for container orchestration.
• AWS Lambda for serverless functions.

Sometimes these tools alone will not satisfy our organizational needs.

We need to build something custom and that is the hard part.

That's what we will talk about today.

Today you will learn:

• What are the components of a successful self-service platform for developers?
• Actionable tips on building self-service platforms.

Key Components of a Successful Self-Service Platform for Developers

Creating successful self-service platforms is pretty similar to creating successful products.

The only difference is that your customers are the developers.

In the business world, successful products have the following components:

• Great user experience.
• Solves a good problem for the customer.
• Monitor customer metrics for any bugs and improvements.

Let's translate these into components of self-service platforms:

User Experience

You have to keep in mind what type of platform you offer and what is your "frontend".

In general, you got three choices:

• Graphical User Interface (GUI) –  Graphical user interfaces, provide a visual representation of the platform's features and functions, typically in the form of clickable icons or menus. This can make it easier for users who are not familiar with command-line interfaces or programming languages to interact with the platform. However, GUIs can be slower to navigate and may not offer the same level of flexibility as other frontends.
• Command Line Interface (CLI) – CLIs, or command-line interfaces, allow users to interact with the platform by entering text-based commands. This can be faster and more efficient than using a GUI but may require users to have some familiarity with the command-line syntax.
• Code – Code-based frontends allow users to interact with the platform by writing code, which can offer a high level of flexibility and customization. However, this may not be accessible or feasible for all users and may require a greater level of technical expertise.

Ultimately, the choice of front end will depend on the specific needs and preferences of the platform's users.

Documentation

Our customers are developers.

As a developer yourself, when you want to use a new package what is the first thing you read?

Documentation?

No, that's probably the last thing people check.

The first thing they check is some code examples or configuration examples.

So the first key to a good user experience is to make sure your platform is easy to use.

So if you are offering infrastructure as code (IAC) then make sure that your configs are easy to write.

The second key is to have good documentation.

What are the characteristics of good documentation?

• Easy to find.
• Don't overcomplicate things.
• Always have a common problems and solutions section.

If you want more tips on documentation, I recommend the following resources:

The final key is to make sure that they can easily find help.

So in your GitHub repo or documentation always make sure that there is a link to a Slack channel where our developers can raise issues that they have.

It's also a good place for developers to give feedback on how we can better serve them.

Automation

Some platforms fail because they are solving the wrong problem.

The time it takes to have things set up outweighs the benefits.

So make sure you're solving a good problem for them and make it easy to use.

For example, if we are gonna set up a platform for deployments.

Then it must have three features:

1. Provisioning and de-provisioning of resources – You must be able to create and delete resources safely. The developers must have some level of abstraction for them to not bear the overhead of knowing how things work but at the same time, they must have the possibility of removing these abstractions and seeing the logs. This is done to make debugging easier for them in case things go wrong.
2. Scaling of resources – They must be able to specify their scaling policies under a limited ruleset. Another important thing to do is to make sure that the default settings are good enough. So make sure to think of some default settings that are appropriate for the general application in your organization.
3. Continuous integration and deployment – This has to be integrated into our CI/CD pipelines easily. So you can create a reusable workflow or have it integrated with the pipeline provider of your choice (Jenkins, Actions, etc...)  

In a nutshell, try to solve a good problem and try to automate it as much as possible.

Monitoring and Logging

As with any successful software, you need to monitor your application.

Not just from the performance perspective but also from the business ones.

Because before doing any optimizations, you need to have metrics.  

Let's take a look at some common useful tools to have.

• Performance/User metrics – We want to make sure our platform has the minimum performance requirements and is being used. If it's not being used or has issues with performance, then we can immediately detect that and fix it.
• Availability and uptime monitoring – We want our platform to be as reliable as possible, we don't want things breaking because this will ruin the trust we have with our customers.
• Alerting and notification systems – We need to have alerts enabled if things go wrong. We don't want our customers to have to be the ones informing us of this breaking.  

Clear Boundaries

Your platform can't be expected to do everything.

Your developers can't expect you to be on call all the time to fix issues.

So to fix all of that you need some sort of platform agreement.

Similar to how AWS has the Shared Responsibility Model.

So to have some time for yourself and your customers, I would highly suggest having a platform agreement.

Action List

Now that we know what makes a good self-service platform, here are some quick-fire tips on creating a great platform:

• Make sure to have support from leadership
• Involve developers in the design and development process
• Prioritize ease of use and accessibility
• Provide clear and concise documentation
• Automate as much as possible
• Continuously monitor and improve the platform
• Establish a culture of trust and accountability

Conclusion

Self-service platforms can quickly increase the productivity of an organization.

But it's not easy to make.

Hopefully, by reading this article, I've helped you build better platforms.

Feel free to check out my blog for other articles similar to this one.

Thanks for reading.