Everything Must Go

One Binary to Rule Them All

In oCIS, ocis is the universal binary. It starts the microcomponents that make up the oCIS core and the ownCloud Web interface. Additionally, it runs the components that allow oCIS to connect to EOS, if EOS is part of the setup. The use of microcomponents would be violated if oCIS were a huge binary incorporating all that functionality. Therefore, ocis is a skeleton that loads most of the functionality by starting the respective extensions. For instance, the ownCloud Web interface for the Vue.js-based GUI is such an extension. Consequently, for every extension oCIS can handle, you control the component's behavior either directly from the command line or by means of a configuration file.

If you decide to deploy configuration files, oCIS lets you choose between the YAML and JSON formats. A single file in /etc/ocis controls the behavior of the oCIS core and the ocis command itself. The individual extensions typically use their own file for determining configuration settings, but the details are left for the authors of the extensions to define. What is elegant though is that oCIS supports sharing configuration files between the host and the individual oCIS containers. Files in /etc/ocis will be present in any oCIS-related container, allowing for a seamless automation of oCIS setups.

A Massive Change in Handling

Overall, the introduction of the ocis CLI binary to control any and all aspects of ownCloud's behavior is by far the most invasive change for experienced ownCloud administrators and will make adapting to oCIS a bit more challenging – particularly for those who have to maintain ownCloud 10 and oCIS setups in parallel (for compatibility reasons or different use cases in the same company). If you are in this camp, you will have to cope with two very different configuration approaches until ownCloud 10 is retired completely.

Monitoring

Massively scalable environments like ownCloud bring new challenges in terms of monitoring. In conventional systems, monitoring usually refers to event monitoring only. Accordingly, the question a typical event monitoring environment will try to answer is whether a certain service at a certain point in time performs according to the desired state.

For scale-out solutions such as ownCloud, that is simply not enough. In fact, the status of an individual component of the setup doesn't matter that much. Microservice approaches are inherently redundant – if one service of a certain type fails, the other services automatically take over that component's workload (gRPC as well as Traefik allow oCIS to follow this principle easily). What is much more relevant to the administrator is knowing ahead of time when additional storage space must be added and when additional servers for oCIS core components need to be commissioned.

This challenge is not exactly new, environments such as Kubernetes or OpenStack have paved the way already and forced developers to come up with mighty solutions. Hence, monitoring usually is just one aspect of what administrators call monitoring, alerting, and trending (MAT). Solutions for MAT in scalable environments exist; Prometheus is one of the most prominent alongside InfluxDB. In oCIS, ownCloud developers add an interface for Prometheus to read out the most important metric data during normal operations.