Philosophy
Analytica comes in two major architecture forms (local and distributed architecture) that allow three different deployment scenarios:
- Laptop Deployment: The key benefit of this deployment is the simple install. It is good for small to medium analytics workloads.
- Server Deployment: This deployment is in support of larger workloads. It also gives access to multiple users using various different clients.
- Mixed Deployment: This combined deployment case is for easy development on laptops while being able to migrate final results to the server for larger workloads.
The distributed architecture is targeted towards larger scale analytics that requires the computing power of servers, while defining the analytics and consuming the results is possible on desktop or on laptop machines as well as on mobile devices.
The local architecture is targeted towards smaller scale deployments as well as the exploration and the research stage for data scientists that want to explore datasets and start defining analytics without having to deal with the distributed server complexities.
The coexisting architecture supports the use case of designing the analytics rules in a local environment while deploying those on a distributed architecture for production use.
Distributed Architecture
The distributed architecture follows a classical client/serer REST-based architecture. The following Figure shows the various components:
Clients, server, and databases can be in different parts of the on-premise network, or even distributed across public, on-premise and cloud environments. For example, the server and the databases can be in the cloud, while the clients can be deployed on laptops. Another scenario could be that the server is on-premise, but the databases are hosted at a hosting provider.
The REST API of the server (based on HTTP and JSON) supports the deployment of the server in any network that supports the vanilla HTTP protocol. The distribution of databases is possible due to the supported remote network connectivity.
Local Architecture
The local architecture follows the exact same component structure, but removes the remote connectivity between the client and the server. As the next Figure indicates through the dashed box, the client and the server form one single process; ideal for local laptop and desktop installations. The database, however, can still be remote (or also local), as needed.
This means that data scientist or anybody else who wants to explore document data sets can do it in a simple way without having to worry about network setup and remote server connectivity.
Co-existing Architecture
The distributed and local architecture are not mutually exclusive. In fact, in larger enterprises they will co-exist for various reasons. The major driver for co-existence is that the local architecture supports the initial phase defining the required analytics, while the distributed architecture represents the production phase.
It is possible to explore data and define the appropriate analytics rules in the local architecture and transfer them to the distributed architecture for production. The next figure shows the overall scenario.
The dashed arrows indicate that the client can not only be deployed in a local architecture environment, but can connect to the distributed architecture as well through the REST interface of the server. This approach allows local analytics design and development and afterwards distributed deployment into production.
Even though not shown in the Figure above, it is possible that the local deployments and the distributed deployment share the same databases. And, they can have local as well as shared databases, providing the ultimate flexibility when using different data sets for different stages of the design – deployment life cycle.