A service in Opereto is defined as follows:


Service = a software executable that can be executed from a shell command


It doesn’t matter how you write the service code and what programming language or software libraries you use. The only requirement is to build your service code as an executable that can start from a shell command (e.g. myservice.sh, python myservice.py, java -jar myservice.jar, myservice.exe etc.).


Micro service = highly decoupled service focusing on doing a small task


Examples of micro-services are: start or stop an instance or a service, send email, send SMS, finds a file with a specific text in it, clean up log directory, get a file from FTP server, seek for particular log lines, etc. Microservices are similar to functions in monolithic applications. They may get some initial input, perform a particular task and return a processed output. Instead of being called directly as functions in code, they are invoked via the network using REST API calls.


In our future discussions, we will make a distinguish between two kinds of micro services: Actions and Flows. However, this is only a semantic difference. Opereto framework handles both types the same.


As mentioned above, all services are executable software programs that run on a specified remote agent host. The only difference between flows and actions is that flows also invoke other actions via Opereto API directed to execute a given remote agent host. 


Action = a micro service that that run on a single remote agent host
Flow = same as action but also invokes other sub-actions via Opereto REST API


Flows are divided into two different semantic types: single-tier flows and multi-tier flows. A single tier flow is a service that invokes a sequence of actions to run on the same agent it is running on. A multi-tier flow is a service that runs on a given agent but invokes a series of actions that run on other agents as well.   


Single tier flow = a flow running all sub-actions on the same agent it is running onMulti-tier flow = a flow running sub-actions on multiple agents


The following chart demonstrates a multi-tier flow execution:




As the above chart illustrates, flows are controlled and coordinated by Opereto center. The flow test service (Flow-1) uses Opereto REST API to run actions and get their statuses and info. As demonstrated, it runs on a dedicated flow agent while the flow sub-actions run on Agent1 and Agent2. 

In general, it is a good practice to map flow services to run on dedicated agent hosts. Let's take for example a situation where we write a multi-tier test flow that performs test actions on a given software under test (SUT) set of agents.


Let us assume that a flow test service runs on one of the SUT agents as well. Let us also assume that one of the test action requires a reboot of that agent. Restarting the agent host also terminates the flow execution on that host. It would be the same as someone cutting off the branch it sits on. Having the flow code running on a separate agent improves the execution reliability of that flow and make it independent of the actions it invokes. 


To learn more about flows, please refer to the following tutorial: Working with flows.


Run services

Executing a service (or creating a new process for a given service) can be done from the Dashboard in the user interface or via the REST API. The user initiating (or registering) the process may provide input parameters to override the default ones, a name to the new process and a list of agents to run this process on.


Once the user registers a process, it will wait until the relevant Agent collects it. It usually takes up to 5 seconds, but the user may reconfigure it per agent. To reduce redundant network traffic, the Agent utilizes a caching mechanism for services. Unless a change had been made in the given service, the Agent would use its local copy of that service code. The Agent runs the service executable and sends all logs, property updates, and execution statuses back to the Opereto cluster.


Modify services

Opereto is an operations framework, not a source control. For this reason, modifying services are the same as modifying any other code. A service developer must commit all changes to the service repository and that re-fetch the service from Opereto UI or REST API to override the service executable stored in the cluster.


Deleting a service in Opereto only deletes the local copy of this service and all processes and schedulers related to this service. It will not remove anything from the source repository.


Schedule service executions

Opereto provides a built-in scheduler for services. The scheduler supports a cron style time specification. There may be one of more schedulers per service. For each scheduler, the service mandatory input properties, if any, must be configured with a default value. Otherwise, that scheduled task will fail.