Datastores
Datastore Modules provide infrastructure and configuration to launch and maintain resources that hold data.
This a broad category of modules to enable automated connectivity of apps to a wide array of vendors and platforms.
- Relational Databases (e.g. Postgres, Mysql)
- Nosql Databases (e.g. Mongo, DynamoDB)
- Cache and Key/Value Stores (e.g. Redis, Consul)
- Message Queues (e.g. SQS, Kafka)
- Object Stores (e.g. S3)
- File Systems (e.g. EFS, EBS)
- Log/Metric Providers (e.g. Datadog, Splunk, Sumologic)
- Other Vendor Integrations (e.g. Sendgrid)
What makes a Datastore?
What makes a datastore in Nullstone unique is how architects and developers utilize these modules. An architect configures the datastore in Nullstone with admin credentials and has exclusive access to perform infrastructure changes. Then, these architects grant developers access via Nullstone to connect their applications through a self-service interface without exchanging secrets or escalating privileges.
As a result, datastore modules serve as a general purpose utility to extend applications and keep them stateless. They configure and store credentials for vendors, create clusters, and prepare those services for easy integration with applications.
Conventions
When creating a datastore modules, you should keep in mind how architects and developers are going to use the module. It is also important to understand the Nullstone conventions to make sure your modules take full advantage of the Nullstone platform.
The following sections outline these conventions and usage.
Datastore Capabilities
Nullstone provides quick access for developers to connect their applications to datastores using capability modules. When you create a datastore module, you must also build the companion capability module to "glue" the application together with the datastore. Without the capability module, developers will not be able to use the datastore.
See Capabilities for more details on these companion capability modules.
TIP
As a general rule, a developer should not need to perform any manual configuration when connecting their applications to datastores.
A datastore module should also provide documentation in the datastore's README.md to guide an architect/developer that answers the following questions.
- How should a developer connect to the datastore directly? (in some cases you may wish to allow access for running manual queries or doing maintenance)
- How should the developer go about connecting to the datastore in their code? (for example, what environment variables for connection strings and credentials are provided?)
- Is there any additional documentation or resources for managing the datastore?
Reuse Capabilities
For some datastores, Nullstone provides capability modules that support multiple platforms. As an example, Nullstone provides the aws-postgres-access capability that enables any AWS application to connect to any Postgres datastore regardless of the hosting platform. (e.g. Aurora, RDS, self-hosted, third-party managed service, etc.) This is possible because the functionality this capability provides doesn't rely on any implementation specific details of the datastore.
To take advantage of these built-in capabilities, make sure to emit outputs from your datastore module that the desired capability needs. In the aws-postgres-access example, the capability makes use of three outputs from a postgres datastore. (See aws-postgres-access/postgres.tf)
Database Admin Functions
Nullstone provides expansive support for common databases. In these official modules, Nullstone created a set of serverless functions that are used to administer the datastore.
As an example, when a developer grants an application access to a postgres datastore, the aws-postgres-access capability utilizes the database admin function (located in the postgres datastore) to create a database in the cluster, create an application user (with a random, secure password), grant that user access to the database, and inject the credentials into the application.
If your datastore's capability modules need to perform similar actions, create and package the admin function as part of your datastore module. This provides a more secure and robust way for the capability modules to enable connectivity to the app.