A multi-territory tourism platform brings three workloads that sit badly together on the same hardware: the ingestion of cultural and geographic data, web services with seasonal traffic, and batch processing over maps and metadata. Before any application design, the question to settle is which infrastructure layer can isolate these workloads without tying the consortium to a proprietary supplier.

Context

The frame here is the PON “Ricerca e Competitività” 2007-2013 programme, whose Notice 84/Ric. of 2 March 2012 opened the “Smart Cities and Communities” line and placed cultural heritage among the eligible areas (ponrec.it). A consortium answering a call of this kind brings together many bodies — small firms, university departments, research institutes — each with its own data centre, its own sysadmin skills, its own portability constraints. The call asks explicitly for open solutions, and that request has precise technical consequences: the infrastructure layer must run on heterogeneous hardware and must stay inspectable after the funding ends.

Piloting across several territories — Salerno, Prato, Pisa, Pistoia, Piedmont — adds a requirement that is easy to underrate: the same service image must be able to run at different sites, managed by different groups, without rewriting the deploy procedure. It is reproducibility before it is scale.

Architecture

In early 2014 the natural candidate for the Infrastructure-as-a-Service layer is OpenStack. The Grizzly release (2013.1, April 2013) holds together seven integrated projects: Nova for compute, Swift for object storage, Glance for images, Keystone for identity, Horizon for the dashboard, Cinder for block storage, Quantum for networking (release notes at wiki.openstack.org/wiki/ReleaseNotes/Grizzly). For a tourism platform Glance and Swift carry the most weight: Glance versions the machine images services are instantiated from, while Swift holds the objects — geotagged photographs, cultural metadata datasets, map tiles — with the quotas and CORS introduced in Grizzly itself.

The scheme that holds the three workloads apart separates the planes cleanly:

  • Ephemeral compute on Nova for the web front-ends, sized for the seasonal peak and scaled down off-season, with KVM or Xen as hypervisor.
  • Durable storage on Swift for the cultural assets, replicated and independent of the compute instances’ lifecycle.
  • Centralised identity on Keystone, with the PKI tokens added in Grizzly, as the single authentication point across territories.

In Grizzly, Nova introduces the cells deployment model and the no-db-compute isolation that detaches compute nodes from the rest of the system: two mechanisms useful exactly when infrastructure is spread across sites administered by different groups. Prototyping need not bind itself to a single platform: OpenNebula (4.4, November 2013) and Eucalyptus remain alternatives worth evaluating, both with drivers compatible with Amazon’s EC2 API. Eucalyptus implements AWS API support, including an S3-compatible object-storage component (Walrus); OpenNebula carries an EC2 driver that submits requests to Amazon as well as to Eucalyptus. EC2 compatibility carries weight: it leaves the route open to lean on public capacity during seasonal peaks without rewriting the control plane.

The critical point

Whether the project is sustainable turns on the storage of cultural assets more than on the compute. Geotagged photographs, work metadata, and map tiles outlive the services: front-ends will change, campaigns will change, perhaps the territories involved too, but the data stays. Keeping it on Swift — an object store with quotas and replication, addressable over HTTP — means choosing a preservation format that depends on neither the individual application nor the individual data centre.

This is where the question of formats comes in. On the cultural-heritage side there are already settled models and APIs: Europeana exposes its data through the Europeana Data Model, serialisable in N-Triples, Turtle, JSON-LD and other RDF dialects, and offers access APIs (pro.europeana.eu). For geographic data, OpenStreetMap offers an open, reusable base map. If the assets sit in Swift and are described with these open models, they stay queryable and migratable even after the project ends: the difference between a research prototype and data someone can still use in 2020.

Implications

Separating ephemeral compute from durable storage has a practical consequence: sizing stops being a gamble. A tourism destination’s web front-end has sharply seasonal traffic; with Nova it is scaled to that profile and compressed off-season, without touching the Swift assets. The consortium pays — in hardware or in EC2-compatible public capacity — for the real traffic curve, not for the peak multiplied by the number of territories.

The second consequence concerns the governance of code and data once the project ends. A stack built on FLOSS components with documented APIs is reproducible by anyone with access to the Glance images and the Swift buckets. There is no supplier to renew to keep the system running, and auditing the infrastructure requires no confidentiality agreement. For a publicly funded project that property is worth as much as performance.

Limits

In early 2014 OpenStack is a young platform: Grizzly is less than a year old and the community’s operational experience is still limited, especially outside the large operators. Upgrades from one release to the next are not painless, and networking (Quantum) is the least mature subsystem. For a research prototype these risks are acceptable; for a continuously running production exercise they would have to be weighed against the greater stability of more conservative alternatives.

There is also a limit no infrastructure layer resolves: the quality and interoperability of the cultural data upstream. If work metadata arrives from heterogeneous sources with no shared model, choosing Swift and EDM keeps migration open but does not by itself produce a queryable graph. That work sits at the application and curation level, and infrastructure does not buy it.

This stack feeds into the PON’s SMARTOUR proposal, where noze handles the software architecture of the cloud prototyping in partnership with 01 Sistemi: https://www.noze.it/en/insights/smartour-proposal/.

https://web.archive.org/web/20131117144636/http://www.ponrec.it/bandi/ https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly https://releases.openstack.org/grizzly/ https://pro.europeana.eu/page/linked-open-data https://www.openstreetmap.org/

Cover image: Rows of server racks filled with equipment in a data center hall, with cabling and network gear visible — photo by Hugovanmeijeren, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Cern_datacenter.jpg