A service in Vamp represents a single microservice.
Throughout its lifetime, a service will have multiple versions. At any point in time, there maybe multiple instance of a given version running in different applications.
This concept of a service that spans multiple versions and multiple applications over time is a core part of Vamp. It enables you to track and compare the performance, reliability and operating costs of your microservices both individually and holistically as interdependent microservices within an application.
The Vamp definition of a service is markedly different from the Kubernetes definitions of a Service.
Kubernetes characterises a Service as a network service. An abstract way to expose a set of Pods using a single DNS name and a load balancing strategy.
An instance of a service in Vamp represents a superset of Kubernetes artifacts. A Kubernetes workload (a Deployment or a StatefulSet) plus optionally, a Kubernetes Service.
Services based on StatefulSets are currently only supported for single tenant and private cloud customers.
Common Scenarios
DTAP stands for Development, Test, Acceptance, and Production. It's a traditional way of splitting up your environments that's been around for decades and is strongly linked to monolithic application development.
As you introduce new product features and bug fixes, new services and new versions of existing services appear first in Development and then progress sequentially through to Production.
At Vamp we strongly believe that DTAP is incompatible with microservice-based application development but if you want to use Vamp to manage your DTAP environments, then we won't stop you.
Multi-region Production is what happens when for performance or legal reasons you run the same services in different data centers. This is approach is increasingly popular as a response to regulations such as the EU General Data Protection Regulation (GDPR) and California Consumer Protection Act (CCPA).
Your different production applications will typically share the same services and the same service versions, though differences may exist in order to satisfy the compliance requirements in different regions.
Regional, Multi-Tenant SaaS is where you allow your customers to select which geographical region and perhaps also which cloud provider they want you to use to supply your service to them.
The applications in each region typically share the same services and the same service versions. As you introduce new product features and improvements, your applications normally need to be updated in parallel.
Regional, Single-Tenant SaaS is where you allow your customers to select which geographical region and perhaps also which cloud provider they want you to use to supply your service to them and you use a different environment for each customer.
The applications that you operate for your customers are typically clones that use the same services and the same service versions. As you introduce new product features and improvements, the applications normally need to be updated in parallel. Though you may need to accommodate different release cadences for some customers leading to a mix of different service versions across your applications.