Configuration Deep-Dive
Introduction
The many environments required by SDLC processes — and possibly several Geo-dispersed production instances too — require application deployments in many distinct environments; managing configurations in each environment is already a challenge. Worse, sharded data sets can create a very large number of client connections, amplifying the configuration problem further. Then, scale-out of read and write endpoints doubles the number of connections. In the end, there can be a lot of connections to manage.
ArgentSea is designed to make this potentially large number connections manageable. Using the configuration architecture in .NET core and a unique Hereditary Configuration Hierarchy, ArgentSea allows application changes to be promoted through staging environments and deployed into multiple production environments. It does this while storing passwords securely and without the need for messy transformations.
ArgentSea Data Connections
There are two types of data connections in ArgentSea:
- A database connection - a data set which is hosted by a single database
- A shard set - a data set spread over multiple database connections
A shard set represents a set of data that is spread among multiple database servers. This structure is common for high-performance data access, since it is usually more cost effective and predictably scalable to have multiple smaller database servers than to build one massive server. Global applications might try to improve performance for their global users by distributing shards in datacenters around the globe. The ArgentSea data access components allow you to query across multiple servers or a find specific record on its corresponding host server.
ArgentSea configuration supports any number of database definitions in the Databases collection, and any number of shard sets in the ShardSets collection. Each shard set can have any number of database connections (shard instances).
 |  |
All data connections have the option of separate read and write connections. If you are scaling-out your data access by sharding your data, you are likely also scaling-out by separating read activity from write operations. Even if you are not yet doing this, being explicit about it today makes a transition later much easier.
This creates a potentially large number of connections. Many of these will likely have similar connection information. For example, all of the connections in a shard set might use the same login information or database name, varying only the server address. To manage this redundancy, ArgentSea offers a unique Hereditary Configuration Hierarchy.