Search…
Use Cases
CLI Guides
References
Creating Blueprints (Alpha)
Admin Setup
Frequently Asked Questions
What is the big deal with on-demand ephemeral environments? Is a single, staging environment not enough?
It’s important for companies to be able to experiment and fail to ensure quality assurance, and a best practice is to use a pre-production environment where developers can test features, catch bugs, avoid costly downtime, and eliminate errors before reaching customers in production. In most cases, this environment is a single, shared staging environment that is available 24/7, and is one of the last phases of testing before deployment to production.
Ephemeral environments by nature only last for a very short time, and can also be described as an environment-as-a-service (EaaS). Below outlines some of the advantages of ephemeral environments over traditional shared staging environments:
Single, shared staging environment
On-demand ephemeral environments
Number of environments
1
Unlimited
Developer self-serve.
❌ One environment, which all developers have to share and get access to leading to “too many cooks in the kitchen”
✅ No learning curve and can work in your native dev toolbox. Any developer can instantly spin up an ephemeral environment on-demand for every pull request.
Low maintenance
❌ Need to manually configure any changes in production infrastructure to sync with the staging environment. Need a dedicated team or time of developers to ensure it’s running properly.
✅ Ephemeral environments are always available on-demand. No need for someone to create them. Any developer can spin up one in seconds, and destroy it when finished. With Velocity, you also get automatic configuration so your environments will always be synced and mapped with what is in your production infrastructure.
Faster Feedback & Collaboration
❌ Developers and teams can overlap each other with a shared staging environment. You can make a change without realizing someone already changed something that affects yours.
✅ Every environment gets its own custom URL so you can review the results of changes visually. Then, it’s easy to share with product, QA, sales, and other stakeholders to get feedback earlier on in the software delivery cycle.
Can test features in isolation
❌ Can't test for every feature branch or PR. Usually just test locally and see if it works on your machine and hope for the best when sending to a shared staging.
✅ Yes. Can test for every PR, feature branch. Anything you need to develop, debug or test against can be spun up with an on-demand environment.
Cost
Pre-allocated and running 24/7. Always using resources.
Use only what you need, and destroy environments when you’re done.
Not another tool to manage! Isn’t this just another headache for maintenance and onboarding to a new solution?
You can build your own internal version and keep everything in-house, but it doesn't mean you will avoid any headaches in maintaining or building them. (and that's before factoring in maintaining production and deployment!) With Velocity, you don't need to learn any new tools, manage multiple tools, or manually sync any changes in production to your production-like environment. There is no vendor lock, so you can always work with Velocity while still keeping your old staging or replication infra. And, Velocity's automatic configuration lets you have on-demand real-time environments that are production replicas - available in a click (well a CLI command, but it's like magic!)
“It works on my machine.” Is that not enough?
Phew! Your code is great (yay!) but do you know if it actually works in production? It’s great to have the ability to test locally, but you also want to ensure your hard work will look just the same when it's delivered to your customers. Velocity lets you develop locally, but with access to your environment’s dependencies in the cloud. So you actually work on your machine, with your dev toolbox, but get the visibility to test against a true, production-like environment. You get to actually say that it works on your machine (and everywhere else!)
Why do I need pre-production environments in the first place? Let me just do feature flags and test in production instead.
We 100% agree with you about the importance of feature flags and testing in production. Chaos engineering? Go for it! Fail, fail again and then make it better. But, not everything can be feature flagged, and not all features can safely be tested in production:
- You don't want to lose customer data
- You can't always roll back code if it breaks production
- Downtime leads to loss of customers and revenue
- Features, where multiple developers are working together or affect many parts of your application, are harder to feature flag
We believe testing is great at all parts of the software delivery lifecycle (SDLC). Testing and monitoring in production is only one piece of quality assurance. Wouldn’t it be better to make sure all the bottlenecks and errors are fixed before production as opposed to waiting to break something? The earlier you can prevent any bugs or errors, the less costly in the long term for your product, brand, and customer loyalty.
Also, if you are working on a new feature that doesn't exist in production, Velocity allows you to get an environment with a future branch of one (or more) components, so you can replicate what will be in production - without having to worry about just deploying it and potentially breaking production.
Do I have to use Kubernetes in order to use Velocity?
No. If your services are containerized and you are running on the cloud, you can use Velocity.
I already have Kubernetes, what is different with Velocity?
Kubernetes is great, but it has its limitations. Velocity offers scalability so developers always have:
- The right data: Velocity ensures you have the right data whenever you need, and at whatever point-in-time, to help with real uses. No matter if you're working on a future feature, or against the current production infrastructure.
- Synchronized environment: Velocity's automatic config and sync means that you're always synchronized with the current production infrastructure in real-time.
- Third-Party Depedendencies: Velocity is tech and cloud agnostic which means you can work with your third-party dependencies. This means you'll have a replica of your application infrastructure, with all its data, context, and components.
- Ability to work in your regular workflow: Velocity makes the developer experience seamless. Stay and work the way you want, with your dev toolbox.
I already use Telepresence, why do I need Velocity?
Telepresence is great, but it also has its limitations:
- You are required to have a kubernetes cluster, and can only use it if you have access to that cluster.
- You have to deploy environments yourself
- You can only develop locally if you have an environment set up on a kubernetes cluster
- You are only connected to the application, but don't have access to data or third party resources. Velocity's environment spins up with the resources you need.
Velocity scales up and provides you with a whole ecosystem to create, develop and collaborate with on-demand environments, whether you have a kubernetes cluster or not.
How much extra is this going to cost me?
Velocity uses AWS Marketplace, Azure Marketplace and Google Cloud Marketplace to allow customers to easily onboard to our platform through the already existing cloud provider account. You pay for your own resources.
However, Velocity analyzes the infra to find the smallest amount of resources needed to run each environment.
We also offer visibility into your logs and environments running so you can see what resources are being used at all times. In addition to destroying environments on-demand, admins can enable time-to-live to set a time of destruction for idle environments after an inactive set amount of time.
What permissions and requirements do you require from our system?
The Setup phase is only executed once, and we can provide you with a Terraform module to be run by your Administrators instead of giving us additional permissions. We also suggest the setup will be completed on a new GCP project, to completely isolate us from your other environments and data.
Velocity uses read-only access for our automatic configuration. So we don't modify anything in your infrastructure. We only modify resources that you use in your cloud account.
Do you store any of our information on your system? If so, what and where?
- Services Diagram: We do not have access to any of your artifacts, we just use this information and pass it to the solution we deployed on your account. The structure we infer from your environment is stored in our backend (MySQL on GCP). We store image names and tags, application parameters (e.g., env variable names and parameters), and connections between applications.
- Authentication: We use Auth0 for authentication. Users can choose to connect using SAML, Google Login, or entering a username and password. Auth0 only stores the user's login information (username + email used), and we use it to associate the logged-in user with your account at Velocity (via JWT tokens generated by Auth0 and passed to our backend).
- Telemetry: Our CLI tool (installed on your users' computers) sends telemetry data about its execution to us (we store it on a dedicated Elastic Cloud cluster in GCP as well). This data is anonymized for internal analytics, and you can opt-out of this behavior at anytime.
Last modified 1yr ago
Copy link
Contents
What is the big deal with on-demand ephemeral environments? Is a single, staging environment not enough?
Not another tool to manage! Isn’t this just another headache for maintenance and onboarding to a new solution?
“It works on my machine.” Is that not enough?
Why do I need pre-production environments in the first place? Let me just do feature flags and test in production instead.
Do I have to use Kubernetes in order to use Velocity?
I already have Kubernetes, what is different with Velocity?
I already use Telepresence, why do I need Velocity?
How much extra is this going to cost me?
What permissions and requirements do you require from our system?
Do you store any of our information on your system? If so, what and where?