Wednesday, 20 December 2017

SAAS : Multitenancy Approach

SAAS : Multitenancy Approach

What Is Multi Tenancy?

 "Software Multitenancy refers to a software architecture in which a single instance of a software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants" (Wikipedia)

In brief, multi-tenancy is a technique that is used to create SaaS (Software as-a Service) applications.

Database & Deployment Architectures

There are some different multi-tenant database & deployment approaches:

a) Multiple Deployment - Multiple Database

This is not multi tenancy actually. But, if we run one instance of the application for each customer (tenant) with a seperated database, we can serve to multiple tenants in a single server. We just make sure that multiple instance of the application don't conflict with each other in same server environment.
This can be possible also for an existing application which is not designed as multitenant. It's easier to create such an application since the application has not aware of multitenancy. But there are setup, utilization and maintenance problems in this approach.

b) Single Deployment - Multiple Database

ln this approach, we may run a single instance of the application in a server. We have a master (host) database to store tenant metadata (like tenant name and subdomain) and a seperated database for each tenant. Once we identify the current tenant (for example; from subdomain or from a user login form), then we can switch to that tenant's database to perform operations.
In this approach, application should be designed as multi-tenant in some level. But most of the application can remain independed from multi-tenancy.
We should create and maintain a seperated database for each tenant, this includes database migrations. If we have many customers with dedicated databases, it may take long time to migrate database schema in an application update. Since we have seperated database for a tenant, we can backup it's database seperately from other tenants. Also, we can move the tenant database to a stronger server if that tenant needs it.

c) Single Deployment - Single Database

This is the most real multi-tenancy architecture: We only deploy single instance of the application with a single database into a single server. We have a TenantId (or similar) field in each table (for a RDBMS) which is used to isolate a tenant's data from others.
This is easy to setup and maintain. But harder to create such an application. Because, we must prevent a Tenant to read or write other tenant data. We may add TenantId filter for each database read (select) operation. Also, we may check it every write, if this entity is related to the current tenant. This is tedious and error-prone.
This approach may have performance problems if we have many tenants with huge data. We may use table partitioning or other database features to overcome this problem.

D) Single Deployment - Hybrid Databases

We may want to store tenants in single databases normally, but want to create seperated databases for desired tenants. For example, we can store tenants with big data in their own databases, but store all other tenants in a single database.
Multiple Deployment - Single/Multiple/Hybrid Database
Finally, we may want to deploy our application to more than one server (like web farms) for a better application performance, high availability, and/or scalability. This is independent from the database approach.

Host vs Tenant

First, we should define two terms used in a multi-tenant system:
  • Tenant: A customer which have it's own users, roles, permissions, settings... and uses the application completely isolated from other tenants. A multi-tenant application will have one or more tenants. If this is a CRM application, different tenants have also thier own accounts, contacts, products and orders. So, when we say a 'tenant user', we mean a user owned by a tenant.
  • Host: Host is singleton (there is a single host). The Host is responsible to create and manage tenants. So, a 'host user' is higher level and independent from all tenants and can control they.

Multi tenancy: It is an essential part of SAAS world. Auto provisioning of tenants, on boarding them automatically are the primary features of Multi tenancy concept. 

Multi-tenant and Single Tenants Architecture

·  What exactly Multi-tenant and Single Tenants Architecture,As name suggest, Multi-tenant Software as a Service (SaaS) is an architecture where multiple companies share the same instance to store their data.  This instance is typically divided (or partitioned) to prevent the companies from accessing each other’s information. This is like high-rise building where the floor plans are generally set but minor cosmetic changes can be made to the individual units. Significant change comes at a much higher cost, On the Other hand,Single-tenant (or hosted) Software as a Service (SaaS) is an architecture where each company has their own instance of the software application and supporting infrastructure. Think of it like a neighborhood community developed by the same architect and engineer where each household has the ability to change and customize their property as desired. By having a single hosted instance the purchaser can tweak and customize the software to meet their needs. 
With the difference and various definitions of the different architectures we can focus on we can immediately compare all benefits and drawbacks with our real time challenges.

a) If Customer decides to run the cloud on-premise, they must bear the costs of the whole system alone.
b) A single-tenant system is generally more expensive than a multi-tenant solution.
c) A single-tenant system is generally not the most efficient use of resources, unless it’s fully loaded. For each instance, the underlying software, such as the operating system and run time libraries, must be updated.
Benefits of Multiple Tenant SaaS 

a) Hardware and Power Economy – A major benefit to multi-tenant is on the cost side. With resource pooling, there are considerable savings in hardware and power. With single tenancy, a separate physical or virtual machine needs to be “spun up” for each customer.
b) Effort to Upgrade – Multi-tenancy has forced upgrades to be seamless, as upgrades can’t require any level of per customer intervention when thousands of customers are upgraded simultaneously.
c) Backups and Redundancy – Creating that level of redundancy would be a lot more technically challenging if tens of thousands of customers each had their own virtual server in each of two data centers.

Drawbacks of Multi-tenant Architecture 

a) Less Customization: As a result of multiple tenants running their business off the same code and database, individual businesses have virtually no ability to customize the software to their specific needs
b) Less Authorization and Time Delay: Changes to the software application could be made and deployed to your business without authorization as you are relying on the same code base as the other (potentially larger) tenants. In addition, future features / functionality could be delayed or removed from the product road map as multi-tenant SaaS providers typically focus on the feature requests (and bugs) submitted by their largest customers

Benefits of Single Tenant SaaS 
a) Maximum privacy: There is only one instance for a user, there’s less risk of another business either accidentally or through corporate espionage snooping on data that doesn’t belong to them.
b) It’s impossible to affect someone else’s tasks. Single-tenant solutions are more popular with enterprise businesses.
c) Jobs with intensive computing requirements can make full use of the system.

Drawbacks of Single Tenant SaaS:

a) If Customer decides to run the cloud on-premise, they must bear the costs of the whole system alone.
b) A single-tenant system is generally more expensive than a multi-tenant solution.
c) A single-tenant system is generally not the most efficient use of resources, unless it’s fully loaded. For each instance, the underlying software, such as the operating system and run time libraries, must be updated.

A multi-tenant Approach depends on the software intended platform,target clients i.e is the client a unique client or the software will be used by a clique of clients. 

What Next
We will see how to design a multi-tenant database schema.

Wednesday, 13 December 2017

Lessons Learnt Developing An Enterprise Application


Well been doing programming for a number of years and the experience gained is far from what the school/college/university teaches. When one gets to  the hustle ,that's when you see the real deal.Working for a consulting company was in a team tasked in building an enterprise application,I have learnt that:

1.# Understand the architecture used
Overtime this has  became so much easier after learning about the architecture that we were using. I remember being confused about this at first(at my current company).
It wasn’t until I did a crash course on layered architecture, offered by the company, that I really understood how to navigate through the code base. I got a very brief overview when I started, but I wish I had a better understanding sooner than I did.

In this article, I’ll share ten lessons I learned from my first project as a self-taught software developer. I was working for a consulting company at the time, and my official title was Software Engineer. The project I worked on was a web application for the public sector.

Lesson #2: Don’t take shortcuts
Half way through my time on the project, we added a lot of new functionality. We were able to do some of this with newer technology. As I still didn’t really understand the value of the architecture we were using, I decided to take shortcuts. This ended up costing time and resources when we had to go back and fix it.

Lesson #3: Do not underestimate the value of the business context

As much as we have an idea of how to solve a problem ,one needs to better understand the project.Most developers run into designing and developing a solution without fully investigating the needs of the client.the initial idea and explanation may look as simple as the word Go but when you get into the actually design midway you are forced to change the design.

Lesson #3: Do not underestimate the value of the business context

An important part of the project is learning the business requirements. I completely underestimated the importance of this for the whole duration of the project and the solution value its supposed to inject to the companies growth. This was an expensive mistake. If you don’t understand the business context of your work, it is very easy to go down the wrong path.

Lesson #4: Do not underestimate the value of being self-taught

This project allowed me to gain a lot of confidence in my abilities as a developer. I strongly believe that, if you have the right tools, you can become an expert in anything.
While I’m not claiming to be an expert, my self-taught learning material was more than enough to prepare me for this project. Keep in mind — the list was much shorter back when I started! This revelation inspired me to write Was studying worth it?

In school you get the basic tools. The research one days as a student and when doing a project is you use google to search for a resource or information is different. Sites to filter and how to ask questions in first one gets trolled for asking wrong right questions i.e the right question asked the wrong way.

Use of tools for unit testing , testing post data like postman,soap ui etc.some code generation tools are available out there and true they wount solve everything but will definitely reduced the code development time.

Lesson #5: Write tests that are fast, and delete those that become obsolete

Our project consisted of many tests. We had an autonomous test suite that ran unit tests, persistence tests, and integration tests. The unit tests took a few minutes to run, but all of them together took a whole hour! I realized that quick tests are best, and there’s no point in hanging on to old tests that are obsolete.

Though the system with each development phase it become more streamlined test cases changed to fit the new requirements.Test cases act as a metrics to measure the minimum standards of teh system output

Lesson #6: Benefit of Version Control


We were using GIT for our version control. Unfortunately, the code we were committing was automatically checked in to the repository. We worked on branches and would commit to one final commit that developers would sum their inputs in. The QA team would pull from it using jenkins as the production platform. With all thumbs up it would act as the release package.

At times an update or commit may overwrite a code through a merge .the version control helped in reversing the code to earlier best stable version.

Lessons #7: Write reliable tests — and don’t forget to maintain them

On top of that, some tests were not always green. They would work sometimes, but they would fail just as often. This would cause the build to be red. As a result, I didn’t really appreciate the value of a red build. Sometimes the build would be red for days because someone didn’t notice that another test had been broken.

Lesson #8: Refactoring should be accompanied by tests

Tests were only introduced an year into the project’s lifespan. Before that, all the testing was done manually. This meant that a lot of the code base didn’t have any test coverage, which is dangerous.Code refactor happened alot. Reafactoring would sometimes introduce defects into our software. By introduction of automated testing ,we were able to track the changes and where the defect was happening .This reduced the project sprint delivery time.

Lesson #9: Developing software is a compromise between business value and software excellence

We used a SCRUM -Agile model for the software development process.Our previous Model V-Model would lead to loggerheads with project sponsors and business development C-Suits. Our SCRUM Model included deadlines for developing, manually testing, and releasing the software with Sprint based deliverables where a demo of progress would be used to base the percentage of deliverables.With Sprint meeting ambiguity was cleared and also served as a best way to define metrics on the project and guide the developers ,testers,trainers,documenting team on the project growth.

Lesson #10. Keep an open mind


Having to constrain the expectations is a bad limitation .with changing technology and needs the project has to consider the technology trends out there.

Final thoughts

This project was a very valuable learning experience for me. Not all projects are similar but the standard pipeline is based on the organization culture.Keeping an open mind will ensure delivery and development of a a great system.