Spirit: An Internal Platform Run as a Product

Alexander introduces the guest: Dima Gaevsky has been with the company for years and now acts as architect and technical product manager for Spirit, the whole developer platform; Dima himself adds that Spirit sits inside a larger division responsible for the company's engineering foundations. Dima started at a contractor working with the company: around mid-2017 he was hired into the customer-acquisition team that Alexander himself led back then. The first engineering job was unglamorous — tidying up the monolith that served most of the unauthenticated zone, writing a lot of SQL and, in his words, learning a great deal of sorrow. In January 2018 he moved from Saint Petersburg to Moscow and joined the effort to break that monolith into microservices while shifting the load onto Google Kubernetes Engine. By the end of 2019 he decided to go into a platform that did not exist yet, and for two years he ran its PaaS part — the console and the core services that act as glue. Later the team was reassembled: by Alexander's account one Stanislav left, and the second one split the technical and product halves of the platform with Dima. Alexander recommends the podcast's first episode with that same Stanislav, where they talked a lot about team topologies.

Dima's department is deliberately mixed rather than purely product: systems analysts, open roles for technical product managers who will own user stories and product discovery, an editorial team that runs the writing process for all the platform's user documentation, and a support team of several people who help developers when something misbehaves or is simply unclear. Asked by Alexander whether the editorial team also does propaganda, Dima answers that it is closer to informing users: monthly meetings about new features and a channel with announcements anyone can subscribe to. A technical product manager here, he explains, is first of all an engineer or a former engineer with a broad outlook who moved into product: a candidate goes through both a system design and a product interview. Dima admits he expected such people to be unicorns and was proved wrong — plenty turned up, some of them quite hardcore engineers.

Dima walks through the portfolio using the division's own diagram, noting that Spirit long ago stopped being one big thing and became a system: his team owns the components involved in the SDLC and then in operations. The develop and build domain currently rests on a self-hosted community edition of GitLab — it holds all the code, a developer creates an application from a template or an empty repository, review happens there, security tooling is integrated into it, and builds run on GitLab CI; GitLab is meant to be gradually replaced with an in-house solution, and the build part to grow into something else in time. Below sits the delivery and rollout block: deploy, a centralised way to ship applications and manage releases, conceived long ago but built only recently, plus an in-house container registry meant to grow into a registry for containers and packages. Alongside are the runtime resources written by the internal cloud's IT infrastructure teams, together with reliability on Kubernetes, access and quota management, and an engine that watches every repository for changes to certain kinds of manifests.

A separate thread is contribution by teams outside the platform: managed databases, for instance, live by that model. The ideology of building the ecosystem is written down, and the contributor guide could in places fill a small book, yet Dima stresses that he hides behind neither the documentation nor a ticket queue: the request still lands on him. Then they discuss whether it fits the product strategy, which scenarios and load profile a new database suits, how mature its tooling is and how the choice lands on the target technology radar — because a new option for users can turn out harmful if it is poorly supported. Component teams help (today a scattering of small microservices exposing APIs; operator-style solutions that reduce everything to Kubernetes controllers are a possible future), as do interface teams and front-end engineers, while with external teams Dima runs event storming to model the target scenario and challenge it with all the stakeholders at once.

Not every block of the platform needs a product manager: deploy, with its moving parts, scenarios and wish lists, does, while the runtime infrastructure is led by an engineer who understands the domain and its constraints himself; Dima has two roles open right now. Most of his time goes on feature design and reviews together with the Spirit and infrastructure teams, on product research such as the regular study of the company's application landscape, on end-to-end projects, meetings with users and strategy sessions; roughly twenty per cent is design work, because the product is a technical one. The ideal picture is different: someone who shapes the vision should have breadth and work on strategy rather than design nearly every feature — though that, he cautions, is still a hypothesis to be tested once he finds helpers. Roles, he adds, are blurred, especially in Russia: an architect in two companies can mean radically different things.

Alexander brings his own frustration: solve a task in the evening, watch the test go green and you feel good at once, whereas an RFC about changing how teams work takes half a year to implement and another half a year to gather feedback on. Dima answers that you need a conceptual model telling you that what you do is worthwhile, plus product practices that return the signal sooner: metrics, research, and an adoption process in which a raw feature first goes to innovators willing to suffer alongside the team. His view of RFCs has shifted: applied badly they stretch the path to a result, and a cascade of tickets and epics loses context at every handover, so he now puts communication ahead of process. Hence the difference between an internal and a public platform: a public one is measured by resources sold and similar metrics, while an internal one answers for what its developers end up building and for how a choice lands on the company's technology radar. He closes with principles rather than reading lists: challenge your own decisions, treat trade-offs rationally, learn not only from conferences but from friends working at companies abroad and from open source, and know your customer even when you are merely writing a library.