Search…
What is Vamp?
Vamp is a Continuous Release Orchestration platform.
We define release orchestration as taking running code and making it “live” (that is, accessible to users) in a predictable, repeatable, and efficient way. The emphasis is on ensuring the release of a new version does not result in a worse user experience.
It is difficult to make manual release processes predictable and efficient. Human operators make subjective decisions, especially when trying to follow repetitive and complex processes.
Automation alone is insufficient. For example, Kubernetes provides an automated, predictable, and repeatable way of releasing code as containerized workloads. However, Kubernetes will not prevent you from replacing good code with worse code. Provided the new code runs for long enough to pass a few simple checks, Kubernetes will use it as a replacement for the current version.
Vamp protects you and your users from the outages caused by replacing “good code” with “worse code”. With Vamp, each release is controlled by a release policy, which contains precise criteria for determining whether the new version is “good enough” to replace the current version.
You set which release policy will be used for different types of release, for example: emergency fixes, planned improvements, or new features. You can select from a library of predefined policies. Either use these policies out-of-the-box, or customize them to suit your application.

Dynamically Learning How Your Microservices Behave

You define what data (metrics) should be taken into consideration when objectively determining what is “good enough” for your release. Vamp provides a set of generic metrics taken from Kubernetes, plus out-of-the-box integrations with widely used tools and platforms. You can add to these by defining technical and business metrics that are specific to your microservices and your application as a whole.
Vamp takes the release policy you set for a microservice and uses AI to determine what a “good enough” user experience is for your application, based on the metrics you define. We call this Vamp Health.
Release policies are dynamic. Each new version of your microservices introduces changes in performance, some of them subtle. These changes might be a result of a deliberate effort to improve the performance of the application, a consequence of adding a new feature, or simply the effect of upgrading a software library.
Whatever the cause, Vamp continuously tracks these performance changes and uses AI to revise and adjust Vamp Health and the underlying metrics used in your policies. When performance degrades over time, Vamp warns you.

Releasing as a Business Decision

At its most basic level, Vamp is a DevOps tool. When you initially use Vamp, it will be to individually release microservices into a few environments, as a way of making your DevOps team more efficient
Vamp provides your DevOps engineers with an holistic understanding of your application, not just the individual microservices. If you provide a dependency map for your microservices, Vamp can go further and manage releases at the application level, delaying the release of new microservice versions until all their required dependencies are satisfied.
Typically, this type of dependency management would be handled by your DevOps team through conversations with their peers, the Product Owners, and perhaps other business stakeholders. Vamp makes it possible for you to separate out these decisions and place control of when to release a new feature with the Product Owners. This makes it a business decision, not a technical one.
Your DevOps team remains in control of what is deployed and when. They have control over technical releases, such as emergency fixes and planned technical improvements. Your engineers also retain oversight of the release policies used for feature releases. However, the decision to release a new feature now sits with the business. This frees up your DevOps engineers to focus on other tasks.
This shift is especially powerful if your business needs to comply with legal or other regulatory requirements before releasing a feature to users. It is also invaluable if you need to roll out new features across multiple applications, for example, as part of a regional or multi cloud SaaS solution.
Making the release process less technical and more goal-focussed also means feature developers can self-manage the pre-production environments more efficiently, and with greater confidence.