DBcloudbin is designed for full application transparency, so that the customer application can keep working with no changes, no matter if the content to be accessed is at the database or at the Cloud object store. Applications keep issuing SQL queries through the database with the exact same query syntax as before. DBcloudbin do the job of taking the content behind the scenes in the case it have been moved to the Cloud.
For achieving that, DBcloudbin creates a ‘transparency layer’ at the database in order to ensure that the application queries remain valid and semantically unaltered and, at the same time, ensuring we record the links to the content moved to the Cloud (so we can retrieve it upon application request).
Transparency strategies
Achieving application transparency can be done with two strategies and both has its use and target scenarios:
- Layered (default). In this scenario, the transparency layer is completely independent from the application database schema. The application database schema remains with the exact same tables, views, procedures … as before. An additional schema (Oracle) or database (SQLServer) is created in order to hold the transparency layer objects and record the links to objects moved to the Cloud object store.
- Inline. A simpler model, transparency layer is created inside the application database and object links are stored as a new attribute in the table(s) selected for being managed by DBcloudbin.
Independently on the strategy used, DBcloudbin constructs automatically during setup the transparency layer and provides a simple CLI command “dbcloudbin refresh” for updating the transparency layer when the application Dev team makes changes in the data model (e.g. deploy of a new release, apply a patch, …). However, transparency strategy is not modifiable once selected for a specific application database so it is very important to understand both alternatives and the use cases where they fit better.
Layered
In a simple sentence, layered mode is powerful and completely transparent but more complex. The main benefit is that decouples very elegantly the application engineering process, ensuring that no one in the Dev team has even to notice about DBcloudbin. Application development can be done with no interference, patches or new releases deployed through a data model that is exactly as defined by the Engineering team. This model also enables to deploy DBcloudbin with commercial applications.
As a downside, the application has to be re-configured after DBcloudbin deployment for connecting through the transparency layer instead of through the native schema. That is, we (typically) need to stop the application, change the DB connection settings and start it again, so in most cases we will have a short service unavailability during setup. We need as well to add a “dbcloudbin refresh” command execution as part of any change management process during application lifecycle that makes any modification in database objects. There are some limitations as well if the application uses native functions or stored procedures (e.g. .NET compiled procedure sin SQL Server) that directly or indirectly references the DBcloudbin managed tables (this is detected and warned during setup).
Layered transparency mode is more suitable for:
- Applications under active maintenance with frequent change releases.
- Commercial applications.
- Applications where Dev team is independent and not controlled by our organization.
Inline
Inline model makes changes to the application data model, ensuring that the potential SQL queries that the client application may issue, remains semantically valid. The affected objects are only the tables selected for being managed by DBcloudbin during setup. It is simpler and the client application does not require any reconfiguration, so it can keep online and operational during DBcloudbin setup. It generates less overhead and databases/schemas are not duplicated. However, database change management scripts has to be reviewed for any data model change that affects the managed tables. We provide several ways to make this as much transparent as possible for a DevOps scenario in a detailed whitepaper.
Inline transparency mode is more suitable for:
- Legacy applications with low to none changes and new releases.
- Applications where Dev team is controlled by our organization (either internal or outsourced).