DISCUSS: The direction of AwareIM SaaS in 2019

[aware_support]

Code: Select all

Is this what Codrin is using now (the plugin)?

Yes

[Markfre1]

Thank you, Vlad, for lending clarity on the issue. Now that I see the roadmap, I think we have to opt for one BSV / Tenantid method. I'm sure MYSQL or MSSQL have scalability capabilities. I read about sharding which spreads the data across multiple database servers, etc. But there are complexities there. I sure there are ways to scale with one database and get really large before maxing out.

I'm using something I call cross tenancy. A CPA might be invited to work on many companies data. The CPA would have one login and be attached to many tenants with a CPAdetai object (specific information for that CPA for that tenant). When the CPA logs in, he sees the list of tenants he is associated with, and it uses his loggedinuser.currenttenant to work in that set of data. So this works in one database. I'm not sure I could log the CPA into multiple different databases. I'm not sure I can have a bsv just for logins, which redirects to another bsv and use that schema. I'm getting to complicated and I have a method which works now.

The concern has always been data integrity, recovery, scaling and I assume this is all available under one bsv if Xero did it for their system. As previously mentioned, they did one database, then sharded it to 40,000 tenants, and now switching to cells which can handle millions. I figure if I get to 40,000, I'll be sipping a Mai Tai on an island and let someone else worry about it.

Case settled for me for now. One BSV / TenantID segregation.

Mark F.

[numberz]

Most of this is over my head but what did stand out in all of this thread was "The Hammer" stating that there were two options, pick one, period.
My understanding is that the REASONS for this entire thread was two-fold, price and security.

1) Price:
Is it feasible to have a SAAS subscription for, say, $39 to $59/month?

2) Security:
I think that I can rule out the need for "medical or government grade" type security...but ultimately, if stuff does happen...would it be rather painless to get a customer up and running quickly with this method?

Much appreciated.

[codrin]

1) Price:
Is it feasible to have a SAAS subscription for, say, $39 to $59/month?
Yes, we have a number of applications on SAAS deployment for a number of years some within the price range above.

2) Security:
I think that I can rule out the need for "medical or government grade" type security...but ultimately, if stuff does happen...would it be rather painless to get a customer up and running quickly with this method?

I can vouch for the ease of getting up and running quickly after restoring a server that got hit by a crypto attack .

[numberz]

Thank you.

[Jaymer]

My understanding is that the REASONS for this entire thread was two-fold, price and security.

1) Price:
Is it feasible to have a SAAS subscription for, say, $39 to $59/month?

2) Security:
I think that I can rule out the need for "medical or government grade" type security...but ultimately, if stuff does happen...would it be rather painless to get a customer up and running quickly with this method?

No, thats not the REASONS for the entire thread.

It was a discussion of physical structure of your database(s) in a multi-tenant SAAS solution:
Do you have a "Tenant/Owner" column in your tables (the original way)(co-mingled)(Aware has video on how to do a multi-tenant setup)
vs.
Using a separate BSV/set of data tables per tenant (not co-mingled) and how to manage rolling out a new BSV/database automatically.

Since 8.4, Aware has integrated a way to create a new BSV when signing up a new customer. So this simplifies creating new BSVs.

ACDC brought up the fact that once you start duplicating your BSV (redundancy) and making little tweaks here and there for customers you are on a Highway to Hell (hehe, anyone see what i did there?). This is true for many development languages so not really unique to Aware - but still a pain. At least if you had all clients PHYSICALLY on the same BSV you don't have to manage 50 different ones.
I think if it were possible to have a Dynamic Connection String that allowed users to log in to a central dispatch BSV, and then set your connection path after Login, then 1 BSV could be used with USER DATA being physically in separate tables.