For any development organization, data is a precious commodity.
To complete development projects, and perform thorough testing, developers and test engineers need to have reliable access to consistent, realistic data. Sales staff similarly need access to reliable, consistent data for demos.
These users need to perform the same tests or run the same demo on the same data over and over again.
What's the most efficient, most cost-effective way to create and manage this data? Databases on demand.
At a high level, databases on demand allows users to create temporary databases. The databases are based on snapshots that are maintained by an organization. Users spin up the databases for a specific task, such as testing or a demo, and then tear them down when the task is complete.
With databases on demand, an organization maintains a set of database snapshots. These snapshots are often data volumes or images that are stored in containers.
A snapshot might produce an empty database with a specific schema, or a database that is pre-populated with a set of data. The snapshots can use different database products and contain sets of data that are tailored to specific scenarios and use cases.
When they need a database to use for development or testing, developers use the appropriate database snapshot to create a temporary database. They perform their tests - adding, removing, and updating the database data.
When they are finished, they tear down the database. After they make some code adjustments, they spin up another database from the same snapshot and run the tests again.
Or before each customer demo, a sales rep prepares an ephemeral database. They run through the demo, performing tasks and changing the data. When they're done, they can tear down the database, or just have the system tear it down for them.
Databases on demand can also support CI/CD pipeline integration.
As it generates and tests each new build, the CI/CD system can be set up to automatically create a new ephemeral database to run its suite of tests against, then tear down the database when the tests are complete.
On-demand databases have several benefits, the most obvious being increased testing efficiency and decreased testing cost.
Databases on demand can increase developer productivity and efficiency.
During testing, being able to create databases very quickly ensures that the database creation step doesn't become a speed bump in the test cycle.
With databases on demand, developers, as well as API automation scripts, can quickly spin up a new database that contains the exact data they need to perform a given set of tests.
They don't need to worry about how they are going to reset a database after they perform the latest round of tests. For the next round of tests, they simply create a new ephemeral database that is identical in structure and data to the database that they started with in the previous round.
Developers also don't need to worry about having to share data or that their testing will interfere with someone else's work. Multiple developers can use the same snapshot to create databases for different development efforts.
Organizations can also produce snapshots that contain the exact sets of data needed. They can ensure that the data is of the appropriate size, has referential integrity, and contains specific types and sets of values - but that it does not contain sensitive data such as customer names and identifiers.
Databases on demand can reduce costs associated with database provisioning. Organizations pay a lot less and use fewer resources to maintain a set of database snapshots than they would to maintain multiple permanent databases.
On-demand databases are only created and active when they are needed.
They are also only as large as needed for the test or demo.
An organization can have extremely large sets of data. However, except perhaps for performance testing, a developer only needs enough data to get accurate testing results. But that data still needs to be complete and valid.
Different development teams or projects also might require slightly different sets of data. They might use different databases, or they might be working on different applications.
With databases on demand, an organization can create snapshots that contain appropriately sized sets of data that have referential integrity. Each snapshot represents a complete database.
Databases on demand include features that allow organizations to achieve further cloud cost reduction.
These features are primarily about making sure that an ephemeral database is active only as long as it is needed, and doesn't take up precious resources after that.
One way to reduce cost is to ensure that a database is torn down immediately after a developer is finished with it.
For example, an automated test script can spin up the database, run the tests, and then as the final step tear down the database.
Additional logic might only tear down the database if the tests are all successful. If the tests fail, then the developer might want to look at the data for the purposes of troubleshooting and debugging.
Another way to ensure that databases don't linger any longer than necessary is to build in expiration.
A database might expire after a fixed amount of time - always expire databases 2 days after they are created. Or they can expire after they are idle for some amount of time - expire databases 2 days after the most recent activity.
A developer can spin up a temporary database to test something out, and not have to worry about shutting it off when done. It goes away automatically in a day or two. Automatic expiration can help to avoid unnecessary cloud costs.
Databases on demand can also support more advanced development functions.
Isolated test environments grant developers freedom to experiment and to foster a clearer, faster understanding of the impact of code changes.
However, setting up and managing isolated test environments for each developer can require additional infrastructure, tools, and maintenance effort. It can also get expensive to configure a cloud environment or set up additional self-hosted servers.
Databases on demand makes it easy for a developer to create the data they need for their isolated testing environments.
Users can also integrate databases on demand into API automation.
They can use API calls to automatically spin up and interact with temporary databases.
Tonic Ephemeral is Tonic.ai's solution for databases on demand.
Tonic Ephemeral features include the ability to create empty databases or to create databases that are populated using data in data snapshots. You can then connect to, use, and manage those databases.
Snapshots are stored in the Ephemeral cache. From an Ephemeral snapshot, you can typically spin up a populated database in under a minute.
The Tonic Ephemeral integration with Tonic Structural provides an easy way to stock Ephemeral with snapshots that contain different subsets of de-identified data. You can then use these snapshots as the basis for new temporary databases.
Get the test data infrastructure you need today with a free trial of Tonic Ephemeral, or connect with our team to learn more.
