As we did SaaS: the practice of building a cloud product on the example of EZ-Login. Part 1. On analytics

Disclaimer
With this article we continue the cycle of materials telling about our experience in creating a cloud product. This cycle does not claim to be comprehensive and versatile, but is intended to demonstrate one of the approaches (we hope, effective) to build a product from scratch. Articles can be interesting as individual developers, architects, project managers, as well as entire teams involved in the creation of commercial products. The background of the issue can be found here.

Idea

Task:
Any IT product is designed to either entertain or solve any business problems (or technical problems) of its target audience. We will leave entertainment aside and we will pass to the world of "Enterprise". The task of the organizers is to determine the range of problems that you can cover and articulate them precisely.

An example implementation in EZ-Login:
The mastermind of the company, Anton Marchenko, had a desire to create a SAAS product, enabling companies to manage their accounts in external services. Since large companies have their own data centers and prefer not to display information flows outside their infrastructure, the product must be both public and have the option of private use as a separate copy within a particular company.
More fully the problems that EZ-Login aims to solve are described in this article.
')
Further, using the highly simplified EAP methodology, it is necessary to determine the terminology and domain model, which will allow us to get an idea of ​​the general application architecture, data architecture, and technological architecture.



Terminology.

Task:
It is required to put together and decide on all the terms that are used. This will also help in formulating the requirements for the system being developed, and help to avoid misunderstandings. The terminological dictionary (glossary) is updated and refined as the product develops.

An example implementation in EZ-Login:
As an example, several terms from the dictionary.
Starting point - we build a SAAS product. What is it?

In October 2011, the US National Institute of Standards and Technology published its own definitions of a number of cloud terms.
However, so far in many articles of the RuNet they interpret the concepts of “cloud” and “SAAS” in a variety of ways. There are constant disputes with journalists and practitioners.
Fundamentally, these disputes take place along the border: “to accept NIST axioms or not.”

According to the wording of NIST, a software product is classified as SAAS if it satisfies the following characteristics:

• is “cloudy”
• the product has a pronounced client-server architecture and the consumer uses the product through some separate universal (typical example Web browser) or a highly specific (for example, client parts of the file services 4sync, Dropbox, Yandex.Disk) client program
• all operations for the control of performance, the application of updates, configuration are carried out by the service provider

With the second and third seemingly understandable. But what is “cloudy”?
According to the NIST specification, a service (product) is recognized as “cloudy” if it has the following five features:

• the consumer interacts with the service on the principle of self-service, without participation in the general case of employees of the service provider (self service on demand)
• the consumer uses the service over the network from any terminal device (broad network access)
• the service provides its customers with resources, organized in the form of pools (heaps, groups) to serve different consumers in the multi-lease model (Multitenancy), with the possibility of dynamically assigning and reassigning these resources in accordance with the needs of consumers (resource pooling)
• the consumer has the ability to purchase and return resources that he no longer needs at any time (rapid elasticity)
• the service has an automatic mechanism for metering the resources provided and used by the consumer, followed by a measured service

In the definition of "cloudiness" we have met the term multi-tenant.
We will add it to the dictionary:

Multitenancy is a multiple lease, a property of an information system that allows one copy of a product (installation) to serve many different consumers (tenants) who have their own separate multiple users.



Subject area.

Task:
It is required to define all entities and their properties with which our product will operate, to classify categories of users, relationships between entities, users and friend-with-friend. Based on the description of the subject area, our terminology (glossary) will be expanded.

An example implementation in EZ-Login:
We define the circle of users and their possible roles.
Initially, the service is installed and configured by the owner - provider.
To work in different territorial markets (different currencies, different financial statements, different domains, different third-party services), we will need separate representatives - resellers.
This service can be used by both business structures (companies) and ordinary people (possibly having other people connected with them - family members and / or friends).
In the case of public use of the service - both companies and people are - tenants of the service.
Provider - provides service availability. The tenant interacts with the reseller of the country.

However, for large corporations with branches (or, for example, ministries with distributed departments), in the case of using the service in a closed corporate copy, other gradations appear:

• the corporation itself becomes a service provider
• a separate branch / department becomes a reseller
• and departments / services become tenants.
According to the functionality of all users, we conditionally divide into classes:

• provider employee - Clerk
• employee reseller - Manager
• preferred tenant employee - Administrator
• ordinary tenant employee - Consumer

The main task of the service is to organize the management of access of tenant employees to third-party services. Therefore, in our glossary we need to put a new description of the entity that we use:

Access - the ability of any employee of the tenant to get into an external service without having to enter your username and password.

Based on the "cloudiness" properties, we need to determine the resources that service tenants can use.
Those for EZ-Login, for example, can be:

• maximum number of tenant employees
• maximum number of accesses for the entire tenant
• maximum number of services to which the tenant can have access
• availability of staff list synchronization with the corporate directory Active Directorty
• availability of one-time passwords
• accessibility to use USB tokens

The above is only a small part of the domain analysis.

Having dealt with analytics, in the next article we turn to the schemes and architecture.