Merge branch 'docs/gb/blueprint/runner-scaling-principles' into 'master'

Add runner custom provider plugin system design principles

See merge request gitlab-org/gitlab!79231

doc/architecture/blueprints/runner_scaling/index.md

@@ -204,6 +204,35 @@ document, define requirements and score the solution accordingly. This will
 allow us to choose a solution that will work best for us and the wider
 community.
 
+### Plugin system design principles
+
+Our goal is to design a GitLab Runner plugin system interface that is flexible
+and simple for the wider community to consume. As we cannot build plugins for
+all cloud platforms, we want to ensure a low entry barrier for anyone who needs
+to develop a plugin. We want to allow everyone to contribute.
+
+To achieve this goal, we will follow a few critical design principles. These
+principles will guide our development process for the new plugin system
+abstraction.
+
+General high-level principles:
+
+1. Make the entry barrier for writing a new plugin low.
+1. Developing a new plugin should be simple and require only basic knowledge of
+   a programming language and a cloud provider's API.
+1. Strive for a balance between the plugin system's simplicity and flexibility.
+   These are not mutually exclusive.
+1. Abstract away as many technical details as possible but do not hide them completely.
+1. Build an abstraction that serves our community well but allows us to ship it quickly.
+1. Invest in a flexible solution, avoid one-way-door decisions, foster iteration.
+1. When in doubts err on the side of making things more simple for the wider community.
+
+A few most important technical details:
+
+1. Favor gRPC communication between a plugin and GitLab Runner.
+1. Make it possible to version communication interface and support many versions.
+1. Make Go a primary language for writing plugins but accept other languages too.
+
 ## Status
 
 Status: RFC.