On 19 September 2022, in the Aula Magna of DIAG at Sapienza University in Rome, the final conference of the PON “Smart Cities and Communities” project SMARTOUR was held, with around fifteen partners — nine SMEs, four universities and three CNR institutes. The funding comes from the Italian PON “Research and Competitiveness” 2007–2013, “Smart Cities and Communities” call — Cultural Heritage area; the stated objective was a platform for tourism and cultural enjoyment, with field trials across several sites. Now that the project is closing, a few technical notes remain on what it means to hand over cloud-native infrastructure as a research deliverable, not as a product kept in production.

Context

A funded research project hands over two things: documents — one deliverable per work objective — and code. The administrative constraint is verifiability: every declared component must exist, be described and, at best, be reproducible by an external reviewer months after the work ends. This grates against current infrastructure practice, where much of the state lives in ephemeral clusters, private registries and secrets nobody versions.

The project’s lifespan covers a large slice of the Kubernetes ecosystem’s maturation. SMARTOUR was scoped when running containers was still a debatable architectural choice, and it closes when orchestration is the implicit default for any multi-component system. In between, the reference project’s API repeatedly shifted the line between stable, deprecated and removed. The first concrete problem starts here.

The standard that moves

The current version at closing is Kubernetes 1.25, released on 23 August 2022. It removes PodSecurityPolicy for good — deprecated since 1.21 — and replaces it with the Pod Security Admission controller, which became stable in the same release. For a system written against APIs two or three years older this is no detail: the manifests describing each pod’s security profile no longer apply on an upgraded cluster. The same 1.25 drops the in-tree volume plugins Flocker, Quobyte and StorageOS, completing the move to the Container Storage Interface.

The problem is not any single deprecation. It is that an infrastructure deliverable has an implicit shelf life much shorter than a document’s. An architecture PDF written in 2020 still reads fine in 2022; a manifest set written against an API that has since dropped three resources does not. For a project whose reporting extends past the end of the work, this creates a standards-drift debt: the delivered system is correct against the version it was written for, and progressively incorrect against the one a reviewer would install today.

The pragmatic answer is pinning versions. The control-plane version, the CLI versions, the base-image digests — no moving tags. An infrastructure deliverable reproduces only if it declares the exact version of everything it takes for granted, the control plane included. A manifest asking for image: nginx:latest is not a reproducible research artefact; the one asking for an sha256 digest is.

Portal architecture

The project’s web portals follow a headless design: the content and data layer is separated from the presentation layer by an API, and the front-end is built as a set of static assets plus runtime calls, rather than rendered by a monolithic server-side application. The choice has a concrete reason: the partners producing field data — urban safety, infomobility, conservation monitoring, cultural access — do not share a single back-end, and a presentation layer that consumes APIs is the only way to compose heterogeneous sources without tying their releases together.

This architecture costs in the number of surfaces to version. A monolith has one deploy artefact; a headless multi-portal system has the content back-end, the API layer, each portal’s static build and the contracts between them. Each is a point where reproducibility breaks if you do not pin it. The separation that makes the system composable is the same one that multiplies what must be documented to make it deliverable.

Multi-tenancy as an administrative requirement

The field trials — among others, urban safety, cultural access in augmented reality, conservation monitoring, infomobility — are effectively separate tenants on shared infrastructure. Not by design choice: it follows from a project with distinct sites and leads drawing on a single infrastructure budget. On Kubernetes the natural boundary is the namespace, with resource quotas and network policies for isolation. With PodSecurityPolicy removed, at the project’s close the prescribed way to enforce per-tenant security profiles is labelling the namespaces under the Pod Security Standards — restricted, baseline, privileged — applied by the new admission controller.

Namespace isolation costs little but it is not a hard security boundary: it shares kernel and nodes, and a tenant that escapes its container ends up on the same host as the others. For a research system with non-sensitive field data this is a defensible trade-off; in the deliverable, though, it has to be stated plainly, because anyone inferring hard isolation from the word “multi-tenant” would read a guarantee into the system that is not there.

Limits

All of this concerns deliverability, not continuous operation, which is another story: a deliverable verifiable at a given date and a service maintained over time have requirements that diverge and partly oppose. The first rewards exact pinning and an immutable snapshot; the second demands continuous updates that, by definition, move the running system away from the delivered artefact. A research project that ends hands over the first; whoever picks up the code afterwards inherits the second, and with it the standards-drift debt accumulated between the version the system was written for and the current one.

I have no post-project operational metrics to report, because the funded phase closes here. The notes stand for what they are: observations at the handover point, where a cloud-native system stops being a live environment and becomes an artefact someone else will have to stand back up by reading the manifests.

The closing account from noze’s side, with the deliverables handed over, is in the insight dedicated to the project: https://www.noze.it/en/insights/smartour-conclusion/.

https://www.iac.cnr.it/convegno-finale-del-progetto-pon-smart-cities-and-communities-smartour https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/ https://kubernetes.io/blog/2022/08/25/pod-security-admission-stable/ https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/ https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md

Cover image: Interior of a data center with rows of illuminated server racks in a machine room — photo by BalticServers.com, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:BalticServers_data_center.jpg