SaaS Offers

Home » Guidelines

Among its activities, Software edition and SaaS-hosted solutions are the big challenges LINAGORA wants to handle. It is also expected to be a growth factor for the company and a way to reach new markets and customers.

This page describes the main lines about the way the SaaS offers have been structured.

Context and History

At the moment these lines are being written, 2 approaches exist. One is used for Twake, while the second one covers all the solutions that historically made up Open PaaS. Eventually, they should converge.

Before detailing them, maybe should we define what we mean by SaaS.
SaaS (Software as a Service) is a way for LINAGORA to provide online services to customers, based on the pay-per-usage principle. The services rely on open source solutions, including those that we developed.

A key part and an important technical challenge for our SaaS approach is about multi-tenancy, meaning having a setup of our solutions that can serve different tenants (customers) while guaranting isolation between them (they can only access their own data) and relying on a common infrastructure (to reduce our costs).

So, SaaS at LINAGORA is not only about hosting solutions for customers, but also doing it in a smart way. Over the 2018-2020, there have been many attempts to deploy our solutions for customers, even on our “own” infrastructure (even if it was rented, e.g. at OVH’s). It appeared these deployments were dedicated to one customer. And every deployment was different, with different configurations (that makes sense), but different Software versions and different procedures. And this is something wrong, as too many different platforms can hardly be managed and maintained over time. Clearly, it does not fit with the internal organization (no full-time team for exploitation) and the teams sizes in the company.

During 2020, LINAGORA has worked on unifying the way we perform deployments and improve multi-tenancy. This is about industrialization and standardization: a common infrastructure, the same Software versions for every tenant, the same procedures for every tenant and even for every Software solution. Upgrading a component for one tenant should be propagated to all the other tenants then. At least, that’s the goal.

SaaS, with pay-per-use, also implies self-service components, for registration, usage tracking, billing, etc. This is the focus of the « SaaS Portal » project, that will also unify several services among the different components LINAGORA provides.

Let’s go back to the 2 approaches for SaaS we have right now.

Twake

Twake has been acquired by LINAGORA in 2020.
Beyond the Software component, Twake is most of all an online platform, capable of handling several customers / tenants. Twake was not so far from SaaS.

The main issue LINAGORA faced was that Twake was originally hosted on Amazon Web Services. Which is a problem since one of the key factor of LINAGORA’s speech is about data sovereignty. To make Twake coherent with the guidelines of the company, it was decided to move Twake on OVH.

Since Twake was using some services managed by Amazon (e.g. the database), some work has been done to land on OVH. Because deadlines were very short, it was also decided to remain on VM-based deployments. Moving to container-based deployments may be considered later.

Additional details may be given later about the way it is managed.

Open PaaS and LinShare

There have been container-based deployments for these solutions since at least 2 years. They have met a lot of problems, many being solved over time. The remaining ones should hopefully be handled over time.

Overall, container-based deployments appear like a serious target to provide multi-tenancy while keeping Software components as simple as possible. Indeed, it is a way to use a same infrastructure for several tenants. And it also provides means to isolate them. Providing such an isolation directly in the Software components is feasible but much more complex (this approach was formerly used but dropped).

Container-based deployments also raise a series of challenges.
The main one is about mastering the related technologies. How we addressed it is described farther.

Main Principles

Open PaaS components used to be tightly integrated. That was a big problem as it was very complicated to understand, setup and debug. So, the first principle is about cutting Open PaaS into quite independent blocks. Independent does not mean there are no relations or network flows between them, but that they can be managed by different teams, with a well-defined functional focus.
The second principle is to have an infrastructure for production and one for non-production (that we call pre-production).
A tenant in production may have bridges with the customer’s information system. This tenant will also exist on the pre-production and should have the same bridges than with the information system. The tenant on pre-production is only here to test integration and upgrades for a tenant: this is for functional test.
On the pre-production infrastructures, there is at least one tenant dedicated to load tests. It has no equivalent on the production infrastructures.
Container-based deployments rely on Kubernetes.
Only applications are deployed in Kubernetes. Databases are deployed on VMs.
Applications and databases live in a different area (data center) than backups.
Database servers are multi-tenants. They host several databases. Each tenant has its own database and credentials, but the underlying database engine and servers / clusters are the same. Elastic Search is the only exception, as the open source version does not support authentication / index segregation.
Each application block has its own database cluster (spread the trafic, separate concerns for exploitation teams: those that manage a block manage their entire stack).
All the pre-production blocks live into a same Openstack project.
All the production blocks live into a same Openstack project.
All the information is either stored in GitLAB (configurations, encrypted secrets) or on LinShare (non-encrypted secrets).
Each block has its architecture and set of procedures documented in a TAD (Technical Architecture Document), whose sources are stored on GitLAB, and tagged as PDF files.

SaaS and Clusters

All the infrastructures live on OVH’s.
Applications and databases live in a given area (GRA), while backups are saved in another area (SBG). Both areas are located in France. For the moment, these SaaS offers are only deployed in France. There may be new SaaS instances located somewhere else later.

Here are the application blocks.
Each one can be managed by its own exploitation team.

SaaS Offers

All the blocks on a same row live in a same Openstack project.
Moving from a pre-production tenant to its production equivalent should only be about changing URLs, certificates and credentials in the application configurations.

The « Identity » Block

This block handles everything related to identity: LDAP, LemonLDAP and maybe later common services (e.g. Twake Console).

The « Trinity » Block

This block handles everything related to the trinty, i.e. features that existed in the OBM solution: agenda, contacts and inbox. These are mainly web applications, without the e-mail servers (as managing e-mail servers is more complicated than managing web applications).

The « Emaily » Block

This block handles everything related to e-mails servers: Postfix, James, anti-spam, etc.

The « LinShare » Block

This block handles everything related to file sharing: normally, this is only about LinShare.

Special case: ES clusters

Elastic Search is not multi-tenants.
There are plans to study and challenge OpenDistro. Reviewing the architecture and the relevance of ES for some components needs to be done also.

Until then, there is one ES cluster per tenant and per environment (production / pre-production). Several blocks can use the same ES cluster, provided it is for the same tenant. Example: the “toto” tenant for trinity and identity could use the same ES cluster.