Search…
Vamp Concepts
Release Agent
Integrations
Services
A service in Vamp represents a single microservice.
Throughout its lifetime, a service will have multiple versions. At any time, there may be 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 differs significantly from the Kubernetes definition of a Service.
Kubernetes defines 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 (Development, Test, Acceptance, and Production) is a traditional way of splitting up your environments 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 DTAP is incompatible with microservice-based application development. However, you can still use Vamp to manage your DTAP environments.
Multi-region Production is what happens when, for performance or legal reasons, you run the same microservices in different data centers. This 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 to satisfy the compliance requirements in different regions.
Regional, Multi-Tenant SaaS is where you allow your customers to select which geographical region and, in some cases, which cloud provider they want you to use for supplying 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, in some cases, which cloud provider they want you to use for suppling your service to them and you use a different environment for each customer.
The applications 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. However, you may need to accommodate different release cadences for some customers, resulting in a mix of different service versions across your applications.
Last modified 3mo ago
Copy link
Contents
Common Scenarios