Income Property Valuator 2.0 is coming soon – this app will mark an opensource release of our popular iOS app, complete with a brand new, opensource GUI! Be sure to check back soon for more news!
We are pleased to announce that we have released our first opensource Python libraries. You can view all the details at github.com/MikaSoftware/.
If you are a owner of a website, the client organization that uses your website is called “tenant” and if your website supports multiple clients, then your website uses what is called a “multi-tenancy architecture”.
When building a large web-application with multiple organizational clients, we have the issue of how data is “shared” among the organizations: Is the data shared, is it completely isolated, or is there a Aristotelian golden mean achieved between the two?
How do we define sharing data? How do we define isolated data? Every organization has data that they want to remain proprietary or data they want to share to the public for consumption. Furthermore, if the organizational clients have a relationship between other clients (e.g. they are franchisees) then what are the implications for your web-application?
The best analogy to explain multi-tenancy is the following example:
– There is a apartment tower which represents a “shared” model.
– There is a condominium townhouse complex which represents the isolated model.
– Every house or apartment unit in both examples represents your business
– Every family member living in each house/apartment unit is your business data (e.g.: invoices, bills, client information, etc).
– If a fire happens in an apartment tower, everyone needs to evacuate. This is what happens with searching in a shared model – you are allowed to search through everything.
– If a fire happens in a condominium townhouse complex, only the family members in single house need to evacuate, but all the other condominium houses remain as is. This provides some safeguards, but also limits database searching and data access.
– What happens if more family members want to move into a full apartment tower? We have to build that tower up! While this seems impossible in real life, in technical terms, this is analogous to what happens in the tech world. We achieve scale by simply purchasing a more powerful server to handle a more powerful database. The technical term is called “vertical scaling” and can be very challenging.
– What happens if more family members want to move into our condominium complex? We have to build another condo! In real life this is very realistic to do and in technical terms, the database remains as is, but we create a new ‘schema’ and everything works. The technical term is called “horizontal scaling”. This is generally not challenging to implement.
– Overall “vertical” scaling is much easier and cost effective to implement than “horizontal” scaling.
I will now go into a real life business example of retail stores and how they would implement a multi-tenant architecture.
Imagine that you walked into a locally owned shop. You purchase a keyboard, and then take it home to use it. The only person who really knows the details of the transaction (apart from you) is the local shop owner.
Now, imagine a chain like BestBuy which has hundreds of retail locations around the world. If you buy an item at one store, this data is viewable at virtually any other store, as well as the BestBuy website. This means that any store can help you with your purchase, and can count towards accumulating loyalty rewards and other benefits that come from sharing your data. While the investment in developing and maintaining something like this is quite high, this allows for a maximum sharing of data with a strong central management. This is really what multi-tenancy is about.
Still not sure if multi-tenancy makes sense for your next project? E-Mail me today with any questions – I would be glad to help!
Today we launched the next iteration of our website. Be sure to check back regularly, as we will be posting updates on upcoming opensource Python libraries.