Vespa Cloud: Operational use cases
Many organizations use cloud services like AWS, Google Cloud and Azure to easily manage capacity. Vespa enables seamless resizing and change of instance types. Vespa has no shards, it uses buckets with dynamic number of bits for distribution. Using cloud.vespa.ai this is just a config change - self-hosted Vespa enables this by adding to services/hosts.xml and some manual steps - read more in elastic Vespa.
Equally important, Vespa applications scale down to 1 - developers can deploy the full application to to own laptop or development environment with no configuration changes. This lowers the bar for making changes, and also enables easy support, as the application can run anywhere (Vespa runs in a Docker container).
As Vespa applications can be very large, node failures are automated as well, with configurable rebalancing speed to regenerate replicas. Within configured data redundancy, the application keeps serving while new instances are auto provisioned. Failed instances are kept for some time offline to preserve data in catastrophic events.
The elastic features of Vespa cloud makes it easy to add or remove nodes by just a configuration change and some wait time for auto data migration. However, it is hard to get the node specifications right from the start - applications change with new features and changing load patterns. Trying to get everything right before launch will also push the launch date out, and requires must testing.
Instead, launch with enough capacity, monitor, and then change both node count and node specifications based on real production load. Changing specifications, like double CPU or cut memory is a configuration change and subsequent auto data migration - read more about resources:
<nodes count="4">
<resources vcpu="8" memory="32Gb" disk="100Gb"/>
</nodes>
Using this flexibility, teams migrating from self-hosted to Vespa Cloud:
A Vespa-application is defined by its configuration and code, maintained in the application package. This changes over time as schemas change and code is modified. To deploy changes safely to production, an explicit validation is required for potentially destructive changes.
This makes changes to production safe, most teams deploy daily or more often. This makes changes smaller, with less risk and easier roll-forward. Use github actions or other automation to build a pipeline that automatically rolls out changes committed to the code repository.
Applications are most often deployed in multiple zones, with failover using a global endpoint.
Software upgrades take both calendar and work time. Testing is required to identify and fix performance regressions. With Vespa Cloud, this is automated and just happens several times a week
All changes to Vespa Cloud is automated - operating system, containers, Vespa software and dependencies - as well as testing the application code and configuration at every change. This is a prerequisite for strong security - there are no stale, exposed components. Applications run the latest, and auto testing makes sure it keeps working.
All external and internal communications is secured with mutual TLS with application-specific certificates.
All applications run on in dedicated and network isolated containers.