What is Vamp?

Vamp is a continuous release orchestration platform but what does that mean?
We define release orchestration as being the act of taking running code and making it “live”, i.e. accessible to users, in a predictable, repeatable and efficient way. Paying particular attention to ensure that releasing a new version doesn’t result in a worse experience for users. 
If there is already a live version of a service, why would you replace it with a less well performing version?
Manual release processes struggle to be predictable and efficient. Human operators make subjective decisions especially when trying to follow tedious and laborious processes.
Automation alone is not sufficient, for example Kubernetes provides an automated, predictable and repeatable way of releasing code as containerised workloads but 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.
In contrast, Vamp will protect you and your users from the outages that come from 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.
As a user, 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. You can use these policies out-of-the-box or you can customise them to suit your application.
Dynamically Learning How Your Microservices Behave
You define what data (metrics) should be taken into consideration when objectively determining “good enough”. 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 defined. We call this Vamp Health.
Release policies are dynamic. Each new version of your microservices will introduce subtle or not so subtle changes in performance. These changes might be the result of a deliberate effort to improve the performance of the application, they might be a consequence of adding a new feature or they might simply the result 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 you policies. When the performance degrades over time, Vamp will warn you. 
Releasing as a Business Decision
At its most basic level, Vamp is a DevOps tool. When you initially start using Vamp it will be to individually release microservices into a few environments, as a way of to make your DevOps team more efficient
Vamp provides your DevOps engineers with a 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 is something that your DevOps team will currently be managing 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 the control of when to release a new feature in the hands of the Product Owners, making 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 that will be used for feature releases. However, the decision to release a new feature now sits with the business. Freeing up your DevOps engineers to focus on other tasks.
This is especially powerful if your business is required to comply with legal or other regulatory requirements before releasing a feature to users. It is also invaluable if you need to rollout new features across multiple application, 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 with greater confidence. Further freeing up your DevOps engineers to focus on other tasks.


​
Introduction
What's New?
Last modified 9mo ago
Copy link
Contents
Dynamically Learning How Your Microservices Behave
Releasing as a Business Decision