If there’s one thing we’ve learned over the past six years of getting developers access to realistic test data, it’s that developers need data fast, and they often need their datasets isolated, too. Which is why we’re very excited to introduce you to Tonic Ephemeral, our newest developer data offering and a true game-changer for creating isolated test databases. If we’ve already piqued your interest, you can sign up for a free trial today, or book a demo with our team. If you’d like to learn more right now, read on…
Tonic Ephemeral makes it cheap and easy to create isolated test and development databases to accelerate your engineering velocity and shrink compute costs. We built it in response to the challenges we’ve seen many customers confront in getting test data into the hands of their developers. They may have the realistic test data they need (thanks to Tonic Relational), but getting it to where they need it isn’t always simple.
Why your developers need isolated test environments
Tonic Relational, our data masking offering, excels at providing data that closely mimics production thanks to realistic data masking. By integrating that data into a broader workflow via Ephemeral, developers are able to work faster and get the most utility from their test data without introducing inefficiencies from a resourcing or cost perspective. Rapid, isolated access, in particular to data subsets, would allow them to:
- One-click through a CI/CD process and get de-identified data spun up in an environment that they can use for testing and development.
- Spin up databases as-needed — for example to reproduce a bug, or for manual testing.
Sounds great, right? But do developers need an off-the-shelf product to unlock these workflows? We think so. 👇
Why isolated test environments aren’t easy to build
It’s common knowledge that isolated test environments grant developers freedom for experimentation and foster a clearer, faster understanding of code impact. But while the benefits are clear, the decision to implement these environments has often been swayed by practical considerations such as provisioning efficiency, infrastructure overhead, and cost concerns. This was something we encountered with Tonic. We’ve seen many of our customers invest time and resources into scripting solutions to this problem while attempting to avoid the pitfalls below, and it is not easy.
Challenge #1: Infrastructure and resource overhead
Setting up and managing isolated test environments for each developer can require additional infrastructure, tools, and maintenance effort. There is also an upfront resource investment that varies heavily based on the level of self-service and sophistication of the workflows.
Pitfalls in low upfront effort homegrown solutions
A process where developers submit tickets to an IT team is easy to implement, but results in long wait times, especially when the IT team isn’t staffed to handle the number of requests and when requests surge. This red tape and the possibility of the request getting denied undercut the efficiency benefit of isolated environments.
Additionally, for environments that include databases, it can become unmanageable to manually track how long the databases are running and follow-up to confirm that the databases can be shut down. This can result in excessive costs for cloud infrastructure.
Pitfalls in high upfront effort homegrown solutions
Investing in sophisticated internal tooling for efficient test environments has its own risks. Building out a more sophisticated workflow requires more investment upfront. It can take 6+ developer months to create a solution that provisions test environments efficiently and automates shutting down unused databases to minimize costs. Such a solution also requires an ongoing investment to keep the tooling running and troubleshoot issues.
It’s often difficult to justify investments in internal tooling like this over projects that are more customer-facing and have a direct impact on the company’s bottom line. There is also the risk that the solution goes stale when key developers who created the tool leave the company.
Additionally, for organizations that do go this route, database setup is often the hardest part of creating the test environment. Setting up databases requires database-specific expertise, and the databases can need to be seeded with data. In comparison, setting up the application server is easy — organizations that use Kubernetes for their production environment already have the configuration for how to deploy their application as a container.
Challenge #2: Cost concerns
In terms of hosting the database, you have the option to configure a cloud environment or set up more self-hosted servers. Either of those options can get expensive, particularly if DBs stay up longer than necessary. Cost concerns are frequently the largest barrier to allowing developers free rein to create temporary data environments for bug reproduction and manual feature testing.
The value of Tonic Ephemeral
By simplifying the setup of databases, Tonic Ephemeral allows you to handle the straightforward task of setting up application servers, leaving the intricate work of creating and managing databases to Tonic.
- Stop losing time provisioning and maintaining databases yourself.
- Eliminate lag and wait-times in sourcing isolated datasets for development and testing environments with quick database copies.
- Take advantage of our built-in expiration timers and other controls for cost savings.
We built Tonic Ephemeral to make it more feasible and practical for you to give developers the isolated test environments they’ve been asking for, and to put the cost controls in your hands. As it happens, our own developers (and budget) are also benefiting from Tonic Ephemeral, and we can't wait for others to reap the benefits.
Sign up today for a free trial or book a demo with our team so you can get the data you need, when and where you need it, and keep your focus on the work that directly helps your customers.
