Currently I am trying to design an application where we have a CosmosDB account representing a group of customers with:
One container is used an overall Metadata store that contains all customers
Other containers will containers will contain data specific to one customer where data will be partitioned on according to different categories of customer history etc.
When we onboard a new customer (which will not happen too often and once) we'd like to make sure that we create an row in the Overall customer Metadata and then provision the customer specific container if fail rollback the transaction if it fails. (In the future we'd like to remove customers as well.)
Unfortunately the Cosmosdb Nosql only supports transactions in one container within the same logical partition, and does not support multi-container transactions. Our own POC indicates the MongoDB api does support this but unfortunately MongoDB does not fit our use case as we need support for Azure Functions.
The heart of the problem here isn't whether Cosmos DB supports distributed transactions. The core problem is you can't enlist an Azure Control Plane action (in this case, creating a container resource) into a transaction.
Since you're building in the cloud, my recommendation would be to employ the outbox pattern to manage your provisioning state for your customers. There's an easy to understand example here you can read.
Given you are building a multi-tenant application for Cosmos DB and using containers as your tenant boundary, please note that the maximum number of databases and/or containers in an account is 500. Please see Service Quotas for more information.
Does Corda node support the concept of an organization and users in the organization? The ORG user must have visibility to transactions of the node. And is it possible to add users within this Organization who can be part of selected transactions?
Yes, you can do it with Corda. I see two ways:
Use the Account library. Accounts are "logical" entities, i.e. subset of the node's vault. An ORG can be the Corda node and the users can be accounts owned by the node, which has complete visibility of the transactions. You can add as many accounts as you want. Note that an account only has public keys, the private keys are owned by the Corda node owner of the accounts. The flows are effectively ran by the Corda node, not by the Account themselves who are just effectively states that only have a name and a set of public keys (but not a X.509 identity, so they are not registered to the network. Only the Corda node is). A typical use case of this is a Group Company X (i.e the Corda node) who owns some Subsidiary Companies (its accounts). More info: https://training.corda.net/libraries/accounts-lib/ and https://github.com/corda/accounts/blob/master/docs.md
Use the Business Network Membership: https://docs.corda.net/docs/corda-os/4.8/business-network-membership.html. In this case you have different Corda nodes connected to the same network, and a subset of these node share a "logical" network, which is made at application level in which you can set the roles and memberships. In pratice, this is a cordapp shared between them where there are states that identify an organization and its rules.
These two above are ways to effectively create "organizations". In Corda then you also have the Observer parties, who are parties that just want to be notified of some transactions without effectively be part of them.
Hi is Corda a recommended platform for Digital Identity? For a use-case of Account based-Certification. (i.e. i as a user store my certificates/Identity on the ledger and access it via a password/key where i would go through a node, at the same time to allow a specified certificate only to be seen by a specified party. Where the control is on the user/account level and not a node level. Which means i could specify which certificate/identities i would want to allow another organisation to access)
for blockchain technologies I understand that the data is duplicated across all nodes as long as the user have the key the user can access his own data even if the node is a newly joined node to the network.
As i understand also Corda doesn't support multiple identities on a single node as it is node basis. What will be the approach for this case using Corda platform?
first of all - Corda is not like Ethereum, Fabric and any other blockchain where all nodes store same common state. In Corda network nodes store only transactions and states they were participating in or observing. So its more peer-to-peer rather than broadcast.
Check here for more details:
https://docs.corda.net/key-concepts-ledger.html
From this perspective Corda is probably not the best candidate for public Identity network.
For solution about self-sovereign identity management I would recommend to have a look at something like Sovrin(Indy). You can use it to build app on top of the platform. Or just learn their design ;)
Corda may have sense in Identity context if there are different organisations and they exchange its members identity info for some reason. Then node will be Identity Manager and store info about people who gave it its credentials of any kind. So Identity will be mere state here, I think. Corda itself will play transport and storage role. Not a blockchain-style decentralized way at all but may be useful in some cases.
Just wonder if a single Corda node can support multiple accounts like Bitcoin does.
A related open question I found on discourse https://discourse.corda.net/t/can-you-have-a-corda-identity-adress-without-running-a-node/1298
From Peter FroystadFroystadP6d
Does Corda support multiple people having accounts/addresses on the network without running a Corda node?
Similar to how Bitcoin allow people to own coins with a private key, but not running a full node?
In the financial world, this would correspond to people having an account in the bank, and they would share facts on a 1-1 basis with their bank regarding their dealings. These customers wouldn't run a peer node however. But they would want a service similar to a Bitcoin wallet that would allow them to access their dealings with the bank
Corda is designed for varied institutions which are not all banks, so it doesn't have a direct concept of "account" like Bitcoin does. If you want to implement customer accounts on top of Corda you need to track the balances yourself and use Corda for inter-institutional transfers. Corda's ability to easily integrate with SQL databases and MQ makes that kind of integration quite easy though.
If you're asking about multiple identities on a single node, so one machine can do both legal entity A and B at once, the answer is: we're working on it.
It is now possible with Corda 4.3 and the new Accounts SDK
https://github.com/corda/accounts
However, it is not a simple drop in replacement for Party and requires changes to an existing cordapp and implementing several parts of the business logic of what you might consider an "account" or "wallet".
According to the blog post by Mike Hearn: https://discourse.corda.net/t/mobile-consumer-payment-experiences-with-corda-on-ledger-cash/966
Note that your balance in this scheme is simply your bank balance. There are no separate wallets.
It looks to me running multiple accounts/parties on a single node is not supported in the moment. Yet, we may expect the support realized in Phase 2 Bitcoin SPV wallet mode.
In phase two this is extended to support a model more like Bitcoin SPV, whereby the sending device manages its own private keys and transaction data. It thus becomes a true wallet app.
I have a difficult database design decision to make regarding multi-tenancy for the growing number of branches of my client's web-based CRM, which I actively maintain.
I made the decision early on to use separate applications with separate databases for each branch, because it was the simplest way to cater for three different branches with disparate data and code requirements. I also wanted to avoid managing Tenant IDs in every query, like I had to with the legacy Classic ASP (cringe) application I built in 2007...the horror.
But now the data requirements for branches are converging and as the business expands, I need to be able to roll out new branches quickly and share global product SKUs.
Since tables and views are the same for all branches and better ORM tools are now available to manage multi-tenant applications, I wonder if it would be better to have a shared database for multiple branches.
Considerations for a centralised database:
Global product SKUs
Simplified inventory requisitions
Easier to backup
Deploy once instead of for every branch
Considerations against a centralised database:
Easier to differentiate branch requirements with separate DBs
Modular deployment (one downed branch doesn't break all)
Harder to manage and develop for shared DB
I have to re-design invoice numbering (sequence generated by seed)
Less WHERE clauses everywhere
Restoring one broken branch has plenty of implications for other branches
It is unlikely there will be ever be as many as 10 branches. Right now there are 3.
Developers with real-world experience in this area, what would you do in my situation? Keep apps & DBs separate, or combine into one giant system?
Edit: Great Microsoft article on multi-tenancy pro's and cons. I should note that data isolation between branches is not a major issue.
Bite the bullet and merge them. Add your tenant ID where it needs to be, and change your queries.
For customizations, look into a plugin type architecture that would allow you to deploy specific screens for particular clients.
We have a software product that is built in just such a fashion. Sometimes it's deployed on a client site, sometimes we host it. For all intents and purposes it is an order of magnitude easier to deal with a single code base that has client specific extensions than dealing with multiple branches of the code.
For one, when we fix a problem, we fix it for everyone. Sure, if we break it, we break it for everyone but that's what unit tests are for. And it is a heck of a lot easier to maintain a set of unit tests against one code base than it is to maintain them for multiple branches.
We've been doing multi-tenant for over 10 years and not once have I looked back. Generally speaking, queries aren't that different if you are already security conscious in verifying that the person retrieving the record is actually allowed to get it.
I disagree with the issues brought up by Corbin. The one around versioning should already be handled by having an attribute based security structure in place. That way you can turn things on/off via user or tenant configuration. Also, I find it very rare that client A doesn't want the same new feature that client B asked for.
The second one about data mingling is also a non-issue. Just look at salesforce.com or any of the other large scale sites. They absolutely use a multi-tenant architecture and judging by the shear number of clients that use them this doesn't seem to be a problem. The main thing here is being able to ensure to your clients that their data is secured.
If you're talking about 10 branches, multi-tenancy seems like a big cost with little benefit.
There are complications with multi-tenancy you don't mention:
Versioning becomes difficult. Clients X, Y, and Z may want a new feature while clients A, B, and C don't. A multi-tenant app makes accommodating everyone difficult, especially if a new feature requires database schema changes. It's not impossible, it's just more difficult.
Some clients are very uncomfortable with their data mingling in the same tables as other clients. Even though we know better, it feels like a security risk to them. Legal departments hate it. In addition, if you ever dump raw data for a client, a shared database requires caution.
You can eliminate a few of your pain points with better practices:
Automate deployment. This should make it easier to add a new client or upgrade/downgrade an existing client. Database maintenance (backups, rebuilding indexes) should be set up automatically as well.
Store shared data (SKUs, inventory) in a central database and have every application instance access it either directly or through a service.
Don't get me wrong, one of the more interesting apps I worked on was multi-tenant. There can be huge benefits, but you'll more likely see them with thousands of clients versus ten.
Honestly, this is a business question. You are either going to be able to deliver more customized features to a smaller user group in a multi-tenant setup but with more IT overhead. That is, you will need more people and hardware (management reads this:money) but deliver greater flexibility.
If you are in a one GIANT Borg situation then you lower your IT overhead (again, people & things, to management money) but your end users have to absorb less flexibility in their software. All bugs are problems for all users, so big ones get whacked fast. However new features impact all users as well so they happen slower.
If you personally have the juice to make this call and the business just has to listen to what you say, or you can nudge management one way or another I'd suggest asking YOURSELF a series of questions about which scenario you prefer:
A) Do you want to have to have more people managing this and share salary/responsibilty
B) To the best of your knowledge is there going to be a 4th user group soon?
C) How long do you want to stay at this company?
If you answer yes to the first two, then you probably want multi-tenant.
I work in a situation where, for regulatory/legal reasons, we have to keep each client's data in a separate database. However, there is certain information that must be shared, mostly related to things like a lookup table for which client's URL corresponds to which database. Also, a client can choose to have multiple databases if they wish to separate their data in some logical way. So, for each of our products, we really have three types of databases:
ApplicationData, which has just a few tables that contain information about the clients themselves, like which MasterData database (see below) to use when reached by a certain URL and which features are available to that client. Each product has just one ApplicationData, no matter how many different clients are using that product.
MasterData, which contains client-specific information such as users, roles, and permissions (in our case, the tables that aspnet_regsql creates are here). Among the permissions specified here are which ClientData databases are available to a given user (see below). The schema for all MasterData databases (for the same product) are the same.
ClientData, which contains the data with which the user interacts. In one product, this is data that the client can search based on a large number of criteria, create reports about, etc. In another product, this contains the dynamic data that a client can upload so that other users can contact people to take surveys over the phone, etc. The schema for all ClientData databases for the same product is the same.
Now, one caveat: We actually use the same schema, and often the same actual database, for MasterData and ClientData. This is for historical reasons, as the ability to allow a client to have one authentication database (MasterData) corresponding to a number of ClientData databases is a relatively new feature that only applies to one of our products. Also, this structure simplifies deployment, since most clients only use one ClientData database. However, MasterData and ClientData have separate entity models under Entity Framework in our projects, and we have to ensure that there are no direct relationships between MasterData and ClientData such as foreign keys.
This setup works pretty well for us. One major advantage is that there is no problem with putting different ClientData databases on different servers. This helps greatly with load balancing, and it provides a natural way to partition data. We can essentially offer a client with a huge amount of data a dedicated database server if they are willing to pay for it.
One more thing that has really helped us in this situation are Red Gate's tools, specifically tools like Multi-Script, SQL Source Control, and Schema Compare. When we upgrade something, and the schema changes, we have to deploy the changes to all the relevant databases. These tools have more than paid for themselves in time saved. Note that I have no affiliation with Red Gate other than as a satisfied user.
Edit: (in response to comment)
ApplicationData is one database per product. The three web-based products we have use the same schema for ApplicationData, since they record basically the same types of information. However, there is no reason it would have to stay that way. The ApplicationData databases are all on the same server. One of the tables in ApplicationData points to the correct server and database name for the client's MasterData, so MasterData for a given client can reside on any server.
MasterData has server and database name information for each ClientData database, so again, the databases can reside on any server. In practice, for now, we only have two production database servers total for these products. The MasterData schema is similar per product, but I do not think they are exactly the same (I would have to check). Each client has its own MasterData. If a client purchases multiple products, there is a MasterData for each product for that client; the products interact in other ways (through web services, basically) if a client has purchased that feature (or requests custom development of such a feature. ClientData for a given product always has the same schema.
So, in summary:
ApplicationData is per product and happens to have the same schema in each product.
MasterData is per client for a product.
There are one or more ClientData instances for a client within a product.
I did oversimplify slightly in that only one of our products supports multiple ClientData instances per client. For a second product, that will probably be implemented eventually. For a third product, it would make no sense at all as a feature and will likely just remain as is.
I hope that answers your question!
Well, if the tendency is towards sharing information and data among different branches you're probably better off having one central database.
Otherwise the hoops you'll have to go through to achieve the ability to share data will be far worse than the extra WHERE clauses needed for a shared DB.
You could, of course, have a DB per branch and an extra database (a fourth database as of now) as a centralized storage for the information that needs sharing. Although you'd have to see if the over-complication makes this a best or worst of both worlds solution :)
If we're talking about CRM, then what are the chances of one customer being in multiple databases? If there's even the slightest chance of you being asked to combine customer details across branches then I'd definitely go with one centralised database.
IMO decentralization is becoming a tenant of maintainable and scalable design. The only centralized database I use is for security for authentication, which I'm currently growing into a decentralized database for authorization. So all authorization can stay at the same edge as the application physically sits with no network traversals since authorization is not a great candidate for caching.
Reading that you're specifically interested in multiple branches of the same application as opposed to truly disparate applications, it sounds like a great option would be to build your database around a seeding process (Entity Framework supports this) that would allow you to just deploy your new branch code to ASP.NET, and then during the initial build up the database that the tables are physically created that you poll the "blessed" server and dump all needed data to the edge server.
After this you would need some replication setup if new products are being added to the primary data store and those are expected to make it to each edge store. You could accomplish this with direct replication of your database or look at tools like the Microsoft Sync framework.
You may think today that you will only have a few customers, but a few years from now you may realize that the product has the potential to be sold to hundreds of customers. If that happens you will regret that you used a single-tenant approach.
Compare the costs of:
Converting a production system from single-tenant to multi-tenant where databases are populated with customer data
Developing a multi-tenant system despite thinking you won't need the benefits
Converting a production system is a daunting and very expensive task.
Using the second approach may cost you more initially, but it does give you a very valuable option to be able to add more customers in the future at low cost. The price of that option could be worth paying.