Our application has 1000+ tenants and we'd like to employ Redis Enterprise to dedicate a database to each of the tenants. Creating each tenant database using Redis Enterprise's admin portal is a tedious task for 1000+ tenants. What's the best way to create the databases in a batch? Any scripts or API to use to achieve this goal?
The Redis Enterprise REST API is pretty extensive. To create a DB just POST Application-json with appropriate auth to https://<cluster_fqdn>:9443/v1/bdbs
"name": "testdb1",
"type": "redis",
"replication": true,
"memory_size": 100000000
}
Therefore you can bulk create DBs. The API has a lot of other useful endpoints at /v1/cluster, /v1/nodes, /v1/users to name a few.
Just a note, you probably want to touch base with your contact at Redis Labs before doing this in production, there might be other details on your specific deployment. They can also point you in the right direction for how to better use the REST API which is supported but not fully documented publicly.
Related
We have an iOS app where users can register, login, and generally do user-specific stuff. We are currently hosting it in Azure SQL DB and using other Azure Services such as Web Applications, Azure Functions etc.
If we want to scale the app for different Countries, we are aware that there are different data privacy concerns per Country. As such, should we be creating different Azure Environments for each country? And develop different versions of the iOS app to point to the specific Azure Environment to use?
Is this is the correct practice? Or is there a recommended pattern / approach for this?
Thank you!
It really depends on the requirement and the end customer, in some cases certain countries have common policies in place.
You can read and understand the best practices and Guidance for Data Controllers when you are migrating/implementing applications on azure
Good morning,
I am using an asp.net framework with an azure client database.
I am now creating another server on Azure to host databases. On this server, for each customer registering on the website (for which 1 entry is created in my first database), I need to create a database with 8 tables - identical for each customer.
What would be the best thing to map the ASP.NET ID to a new database? Which framework would you recommend?
Thanks
Rather than running a VM where you're going to have to manage a SQL Server installation and write a bunch of code to handle a database per tenant scenario, I highly, highly, highly recommend taking a look at Azure SQL's multi-tenant sharding support. All of this code is already written for you. And it's not that you're paying for one DB per client - check out elastic pooling.
You can read the docs here.
Also note, this option will scale very well.
I have done this three different ways: a database per client where I wrote my own code to manage sharding, a single database with a separate schema per client (a huge pain in the rear), and using Azure SQL sharding support. It's not just the issue of correctly separating client data. You also need to think about querying for reporting across all client databases, and managing schema changes. Under the first two options, if you change a schema, you get to modify N client databases. Azure SQL's sharding tools will manage this for you.
I'm trying to get some advice on how to approach a security architecture on Azure.
Background:
We are looking at building a multi-tenant app on Azure that needs to be extremely secure (personally sensitive data). The app will be accessed by standard browsers and mobile devices.
Security access types:
We have three types of users / access types...
1 - plain old user/password over https is fine, accessing both general, non private SQL plus hosted files
2 - user/pass over https, but need authentication of users via certificates that will be installed on user machines/devices. This level of user will need access to sensitive data which should be encrypted at rest both in database, and also any uploaded files.
3 - same as (2) but with the addition of some two factor authentication (we have used YubiKey for other things - might look towards a phone OTP offering as well)
Most users will only have access to their own tenant databases, however we have "account manager" type users that need access to selected tenant data, therefore we expect that they will need either a copy of one certificate per tenant they serve, or we will have to use some kind of master certificate.
Database type:
From a multi-tenant point of view it seems Azure Federated SQL is a good way to go because (a) we simply write one app with "TenentID" key in each table, and after login, set a global filter that handles the isolate for us (b) we understand that Azure federated SQL actually in the background maintains separate SQL database instances per tenant.(Ref: http://msmvps.com/blogs/nunogodinho/archive/2012/08/11/tips-amp-tricks-to-build-multi-tenant-databases-with-sql-databases.aspx)
Can anyone point to any links or give advice in relation to the approach needed to setup and manage file shares, encryption of SQL and file data at rest, authentication of users etc. (automated management on new user signup pref).
I can't really help on the certificates, but you will indeed need some "master certificate". If you are planning on using Azure website, you can't use your own certificates currently.
Concerning the database setup. SAAS applications build on trust, so you NEVER (EVER) want to be showing or editing the data of using to other users.
Therefore I strongly suggest that you don't use the TenantID for each table. This would leave still the possiblity of an attack by a malicious user or an error by some developer.
The only way to get around these risks are
extensive testing
physical different tables to store each tenant data.
Personally I believe that even with very extensive+automated testing you can't have 100% code coverage against malicious users. I guess I am not alone.
The only way out IMHO is physical different tables. Let's look at the options:
different server: valid, but pretty expensive in azure
different database: valid, less management overhead but same objection as the previous option - expensive if you have a lot of tenants
different schema's: the solution. Think about it...
you only have to manage users and there default schema's
you can back-up schema's using powershell
you can move schema's to other databases with some work
You can still digg into SQL federation if you need to.
the major drawback is that you will need to support database upgrades for each tenant.
Have you read on azure.com any articles about multi-tenancy? http://msdn.microsoft.com/en-us/library/windowsazure/hh689716.aspx
I have a website that I've built (hosted on Amazon S3) and it works great. The only problem is that all of the data is static. I'd like to create a SQL database in the cloud that would allow me to store basic text data from users after they submit forms. I'm still a novice web-developer but I've used sqlite3 for several of my Java desktop apps and I'd like to use that SQL knowledge to create this online database. I guess what i'm asking (in my ignorance) is: how can I create a sqlite-type database that is stored in the cloud and that I can query against using javascript?
Where do I get started? Is there a service like Amazon AWS or Azure or something where I can create this database and then use some sort of jQuery/Javascript API to query data from it? I don't need a ton of storage space and my queries would be very basic SQL type stuff.
Any help would be greatly appreciated. Thanks in advance.
For more flexibility, less service lock-in, and cheaper scalability: I would suggest CouchDB (though you would likely still use a hosting service like Cloudant). CouchDB can host your website, and provides a HTTP API for storing data, to which your client-side JavaScript can make REST calls.
StackMob has a free package that you can use. You can use the JS SDK to write your HTML5 app and save stuff to the StackMob DB. You can host your HTML5 on StackMob for free and point your own domain to it as well. There is also S3 integration.
Some references:
JS SDK
JS SDK Tutorial
Hosting your HTML5
Custom Domains
Create a Postgres database on Heroku for free.
https://devcenter.heroku.com/articles/heroku-postgres-plans#hobby-tier
As you mentioned your website is hosted on Amazon S3 I am sure it is a static website with lots of JavaScript embedded HTML files. Due to having a static website, I can understand your requirement to use a database which can be connected from your static site and to be very honest there are not a lot options you have. Static website are considered to have no dependency on database so honestly you have very limited choice because what you are looking for is "A Database which is accessible over HTTP which you can call from scripting language withing HTML"
If you have ability to write back to S3 directly from your JavaScript code you can create a JavaScript based database within your static site which is complex but consider a choice.
In my thinking you are better off to have an extra-small instance in Windows Azure (or your choice of cloud service) and connect with a cloud based database which will be comparative cheaper and fit for your requirement.
Or unless Amazon can come up with a DB accessible from status content as S3, you really have no great choices here.
Since you are already familiar some of AWS's offerings, you should check out:
Amazon RDS - Managed Relational Database Service for MySQL or Oracle
Amazon DynamoDB - Fast, Predictable, Highly-scalable NoSQL data store
But to do what you are asking (access data via JavaScript), check out www.stackmob.com. You can host an HTML5 application with data access via backbone (javascript based framework) on StackMob.
Create a Virtual Private Server on Vultr.com. It's not the easiest way, but it's the best way for you to learn about Database Security, and it will be significantly cheaper than the other solutions, should your server begin to require more storage.
[vitrobridgedb] is free for hobby applications and pretty straight-forward to use
SQLite isn't really a good choice for web facing applications due to its scaling issues.
Both AWS and Azure support SQL databases. They also each support alternatives like MongoDB and Redis. For something as basic as you describe the only real difference is cost.
we have several sites for several different clients, each with several different databases.
Some of the databases are at client location, some are on our site.
I have been tasked with creating a few sharepoint sites that will display information from the databases.
Is it okay to call stored procedures from my sharepoint sites? Since the database is not for the sharepoint site, I feel like that site should not have direct access to the DB and should get the data through web services. Certainly, this would be the case if the data were exposed to another company, but since we are responsible for all of it, is that okay?
In my opinion you save yourself from lot of trouble by just going directly to the database, since you control both ends. The direct access to DB will also have better performance than writing some web services in between the two systems.
If the other system wouldn't be yours, I'd definitely hope that it had a web services (or RESTful web services) interface. My reasoning here is that in most software, web services are really actually meant for integrations and thus changes to them are kept at minimum. Database schema changes are fairly typical during the lifetime of a software product and thus it's not generally easy to evolve the schema if other people build integrations directly against the DB.
Querying the database directly is not a supported scenario, thus you shouldn't ever need to do that.
Best practice is to use the existing Web Services, or implement your own custom Web Service.