With the 7.0 release Innomatic is making an important leap forwards in terms of technology.

In summary Innomatic 7.0 introduces a new technology stack referred to as "Platform" next to the existing Innomatic 6.x technology, herby referred to as Legacy. Platform Stack will throughout the 7.x series mature for each release until it becomes ready to be next evolution of Innomatic. This approach allows for very high degree of forward and backwards compatibility.

Why this change in technology?

Like many other projects in PHP started long ago, Innomatic was an ecosystem isolated from others for a long time because there were no adequate standards of interoperability and open source code available in the form of libraries was often low quality.

It is for this reason that since 2000 Innomatic has a database abstraction layer, since 2001 has its own system of dependencies and distribution of code and PHP applications, and so on: although Innomatic's goal has always been to build multi tenant applications and SaaS-oriented platforms, to overcome the above mentioned problems Innomatic provided its own internal framework, oriented to the type of needs that Innomatic wants to solve.

In recent years, however, some major changes as the massive adoption of Composer and the birth of the PHP Framework Interoperability Group standards as the PSR-0 have exponentially increased sharing between projects and the quality of open source code, becoming the de facto standard.

This also led to a clear separation, even in terms of perception, between old-style, badly written projects (which have often contributed to a low reputation of PHP) and high quality code: PHP has become much more interesting and mature in these recent years and very well written frameworks like Symfony, used by most of the best PHP programmers, have arisen.

All this has forced us to ask ourselves a very important question for the future of Innomatic: should we continue to develop our internal framework under Innomatic, strong of more than 15 years of development and experience, or should we rest on the shoulders of giants, embracing a wider community and build over it?

Although it is not easy to throw away a part of our work to which we believe a lot, we decided to take the second route, progressively migrating Innomatic's foundations towards a system based on Composer packages and full stack Symfony.

What will be gained?

This is an incredible opportunity for our community, customers, partners and for ourselves:

What are the changes?

The version 7.0 in the pipeline will not have many new features but will be the basis for the development of new foundations: on the first hand we will start the development of the new features and migration of the old ones in the new platform distributed as Composer packages, from the other hand there will be a progressive integration of Symfony, discarding parts of the old framework for which there is a better component among those in Symfony.

In this process we will ensure total backward compatibility for standard applications that use Innomatic and for custom projects based on it, thanks to the inclusion of the legacy system inside the new platform and the use of the same database. The legacy code can access the new platform and vice versa, with a design inspired by eZ Publish, made by our friends at eZ Systems.

Since Innomatic is not composed of a set of "static" files and dependencies defined by a file written by developers (“composer.json”) but is a platform that change itself in run time with a growing system of components based on the packages installed and enabled to the various tenant by users and system administrators, even new style applications for the new platform will be in part based on Innomatic dependency system.

However, both legacy and new applications may define their dependencies to classes distributed via Composer (like Drupal Composer Manager) as well as define their own components and dependencies to other applications with the standard Innomatic system and will in turn be distributed as Composer packages.

The 7.x generation will be the bridge to the next 8.x generation to be launched once the migration from legacy stack to the new platform has been completed.

Understanding the new architecture

Target architecture

 

Multi tenancy strategy

The main strategy for separating tenants in Innomatic is multi tenancy at code level and single tenancy at database/data access level: a database for each tenant, plus a centralized root database. By default, inside Innomatic there are no hard coded limit at how many tenants can be created.

Innomatic also provides a Root mode that is executed when outside of tenant context (eg. when administering application and tenants in the root control panel).

 

However, when used as an enterprise application platform for a single company, multi tenancy may not be a requirement. In that case, Innomatic is still suitable as an application platform with its enterprise level features and there is no need to create different databases for Innomatic root and the single tenant.

Multi tenancy can be disabled during Innomatic setup, so that a single database is created. When in single tenant edition, Innomatic allows the creation of a single tenant. Also, installed applications are automatically enabled to the unique tenant (this is different from the multi tenant edition, where applications must be manually enabled to each desired tenant).

Once installed, there's no way to change the single/multi tenancy setting.