Susa Tünker, Product Manager @ Score: From Philosophy to DevOps

Could you please tell us about yourself?

I’m a product manager at Humanitec and a contributor to Score, an open source project that aims to simplify application delivery for developers. I made my way from studies in philosophy and journalism over to JavaScript full-stack development and eventually landed in the DevOps space, where I’m particularly involved with the developer experience aspect. I’m eager to get to the bottom of pain points and bottlenecks that developers face in their day-to-day work and explore ways of reducing friction along the application delivery cycle.

The Code

Why did you start your project? What problems does it solve?

Score solves the problem of cognitive overload for developers.

What we observed over and over is that cloud-native developers are drowning in the complexity of their setups, which are likely comprised of tools such as Kubernetes, Helm, Kustomize, Terraform, or similar. The DevOps mantra of “you build it you run it” increasingly moves out of reach when looking at how things play out on the ground.

For many teams, a specific pain point seems to exist around keeping different environments - such as local and production - in sync. Teams are confronted with a zoo of YAML files, such as compose.yaml (Docker Compose) for local development and deployment.yaml (Kubernetes), values.yaml (Helm) or main.tf (Terraform) for remote environments. Applying changes across different environments and tools that each come along with their own configuration constructs, rules and settings easily ends up in a complex endeavor.

As a developer, you’re not necessarily familiar with Helm or Terraform, meaning you might end up being blocked when needing to conduct a configuration change or declare a resource dependency on your workload. Score was developed against this background. It attempts to solve the above-described problems by providing a tightly scoped workload spec (score.yaml), as part of which developers declare their workload’s runtime requirements in an easy and accessible manner. It abstracts away unnecessary environment- and platform-related configurational complexity while reducing the risk of configuration mismatch between environments.

What was your key driving force in starting your project?

Observing the bottlenecks cloud-native developers run into and the mental toll it takes on them. With the pressure to innovate weighing heavy on teams, added responsibility and infrastructural complexity easily result in cognitive overload and frustration. This becomes evident when looking at the landscape of tech and tooling out there. In practice, developers might lack experience or are simply not as willing to acquire an entirely new set of skills. They will rely on colleagues or operation teams to unblock them. Others might be more qualified or open to taking initiative.

Either way, the chance of individual members within a team feeling disempowered or overwhelmed is high.

Understanding how an infrastructure- and tooling-oriented development approach impacts developers in their day-to-day work was the main driving force behind Score. We intended to not only design a tool that helps mitigate symptoms (such as configurational complexity, out-of-sync environments, etc.) of the underlying problem but also address the root cause by enabling application development that puts the developer and the workloads they are working on first. We want to encourage teams to rethink their way of working through the eyes of developers, who are on the receiving end of all of this.

What's your business model, and how have you grown your revenue?

Score is an open source project and will therefore not be monetized. We measure our revenue in GitHub stars! 🌟

What is the most challenging problem you faced when building your project, so far?

A lot of developer tools out there provide abstractions of one kind or another, which intend to make certain bits of tech and tools more accessible and allow developers to keep their focus. While this sounds great in theory, does the challenge lie in finding the right level of abstraction. Go too specific then you’re only useful to a select few, but go too general and it doesn’t solve anything useful for anyone.

Bottlenecks typically arise, when developers go off path and wish to reveal any of the hidden complexity. This might be necessary when experimenting in a new testing set up or when running into an error that requires a fix in a deeper level system for example. Finding the right level of abstraction in the context of Score has been a challenge and is an ongoing topic of discussion. The approach we landed on can be described as "layered abstraction": The developer can choose how deep they go. They can stay on the top level of Score or dive down to the last Terraform file. We also aim to provide sensible defaults to reduce cognitive load while allowing for easy extensibility and customizability. For example: The Score Specification file (score.yaml) is a tightly scoped workload spec that covers most common configuration items. If users have a specific use case e.g. needing to define a Kubernetes label or annotation as part of their workload, they can do so via an extension mechanism.

This way we abstract away initial complexity while allowing users to step out of it anytime.

What is your team's structure/topology?

The team behind Score includes technical leads, engineers, a documentation writer, and myself in the role of a product- and project manager. We typically work quite collaboratively, without specific structures or hierarchies in place.

What is your vision for your project? How do you see it in 5 years?

I’m envisioning a growing community with lively discussions around topics such as cloud native development, configuration management and developer tooling. Score should not only be seen as a tool but a way of doing things. That’s why we’re hoping to create a space where developers come together to share experiences and explore new ways of working. My vision for the tool itself? An extensive suite of Score implementation CLIs, a well defined extensions library for the Score spec, which covers a variety of use- and edge cases as well as a developer knowledge base with educational content for all kinds of developer personas.

All of this is described in our roadmap in more detail.

What are other projects you’re building?

Score is keeping me quite busy for now, to be honest. I’m curious to learn about other projects in the space though. If something comes to mind, definitely send it over!

What is the best way for a developer to contribute to your project?

You can start by reading through the list of open issues and roadmap items to see if there’s something that piques your interest. Other than that, just have a look around! Score is still early, which is why we’re eager to collect as much feedback as possible. Any insight thought or idea you have presents a helpful contribution, which will help to shape the future development of the tool. If you’d like to get involved, you can join our community Slack.

The Human

What are you currently learning?

I just signed up for a ceramics class! Other than that am I constantly looking to improve my know-how around cloud native tooling, specifically within the Kubernetes ecosystem.

If you had to share one piece of advice that project managers working on open-source projects should follow, what would it be?

To have a clear structure and collaboration processes in place on day one. Being used to managing private team repos I was surprised by the complexity of maintaining open source repositories. This is especially valid in a multi-repository set up like ours, where changes often need to be applied in several places. The team was confronted with change requests and issues scattered across the GitHub org and keeping everything in sync turned out to be a challenging task. Investing time early on to create guidelines and standards ensures that everything stays up to date and is consistent.

If you had to suggest one person that developers should follow, who would it be?

@luca_cloud (https://twitter.com/luca_cloud) and @njuchi_ (https://twitter.com/njuchi_)

If you had to share one book that our readers should read, what would it be?

I highly recommend Pachinko, it’s a great book. Also recently started with “Breath: The New Science of a Lost Art” which is very interesting so far. If you have limited time, a New Yorker short story won’t disappoint!

Finally, is there anything else you’d like to share with our readers?

I’d be curious to hear about everyone’s experience with the issues I touched on above (such as configurational complexity or out-of-sync environments). You can add a discussion topic on GitHub anytime or just ping me directly via Slack, Twitter or LinkedIn.