Simple Job Scheduler vs Enterprise Solutions
Likya Teknoloji, currently focused on development of two different Work Load Automation Products to provide solutions for wide range of business requirements on the market.
TlosLite, 1.0 released at year 2008, going on its journey with latest version 1.7.0 and proved its stability by existing over 4 years on prominent companies. Second one TlosSW has just completed the first level of development as product and waiting for the time to be on the stage.
It is not going to be completely wrong if we name TlosLite as Simple & Powerful solution. It targets to provide solution for the small or mid-sized companies’ request beside divisions and departments of big companies. If we talk about TlosSW, it should be defined as single and/or multi instance, w/wo agent enterprise workload automation solution that has the ability of workload distribution and remote process execution that is especially targeting enterprise size requirements.
Ability of distribution of workload through the resource on the cloud is a must for the enterprise level solution providing products for the workload automation market.
Here one should rise question; if it is possible to execute remote processes without agent, why should I prefer the with-agent solution that will bring more complexity and the remarkable rise in the cost ?
Here we should technically discuss the architecture and define the term agent and describe roles of the agents. Simply, an agent is an application that is deployed on any platform on the network and executes the orders provided by the host server via asynchronous communication and helps the server for job management feed the server with relevant reporting information produced during process execution lifecycle.
Actually, remote process execution without agent looks like simple but it contains important pitfalls.
Some of the parameters of the remote jobs should be defined carefully regarding environment of the execution platform that may mostly vary between different platforms. For example, if you are planning to execute a shell script remotely, possibly it will not behave on the remote platform similar to local as expected.
Second one of the restrictions is the requirement of 100% up & tuning network connection requirement during the job execution. Otherwise result or current status of the executing process cannot be retrieved under the circumstance of the loss of the network connection. Possibilities, it will continue to work or not, or be terminated successfully or fail and the controller program will never be informed until connection is up. If the long time jobs are the subject, the high risk should be realized.
In such conditions, it is a killing requirement to have 100% percent up & running network connection between the scheduler and remote platform that the job will be executed on.
Loosely-Coupled & Tightly-Coupled
At this point it should be slightly realized that this kind of solution cannot be named as distributed workload management. At most we can say remote job execution. From this point of view, TlosSW with agent, can manage the workload automation process and distribute load according to built-in intelligent workload distribution algorithms with fire & forget principle which is affected by the network faults on very low level.
With the information including TlosSW, another question that may come to mind; Is it possible for TlosLite to find a place on the market that is full of Enterprise Level Schedulers providing solution for the major companies?
The restrictions previously mentioned have the answer to this question actually. TlosLite, by its nature, does not overload its execution platform and can be deployed without any performance issues. Beside, as all the jobs are executed locally it is not necessary to make any configuration on jobs for TlosLite. We may add the cost advantage of multi-instance deployment compared to enterprise products.
After all, if it is required to execute jobs on more than one server, it is possible to install multiple instances of TlosLite to execute these jobs and manage these instances with MC- Management Console application centrally in one place without being effected or with minimal effect of the network failures. It is also possible to define dependencies between TlosLite instances if it is necessary.
With TlosLite, while executing jobs, it is not required to have high quality network for execution except for the cases that the job nature requires.
As a result, powerful scheduling products without agent cannot compete with TlosSW, also not even with TlosLite which is providing benefits of the ability of network-error-free operation systematic.
Therefore, when our products are compared with the competitors, our customers deciding not to prefer TlosLite are going to face the problems of not having distributed architecture that will result losing the reliability and stability.
Tlos Schedulers
TlosLite, 1.0 released at year 2008, going on its journey with latest version 1.7.0 and proved its stability by existing over 4 years on prominent companies. Second one TlosSW has just completed the first level of development as product and waiting for the time to be on the stage.
It is not going to be completely wrong if we name TlosLite as Simple & Powerful solution. It targets to provide solution for the small or mid-sized companies’ request beside divisions and departments of big companies. If we talk about TlosSW, it should be defined as single and/or multi instance, w/wo agent enterprise workload automation solution that has the ability of workload distribution and remote process execution that is especially targeting enterprise size requirements.
Ability of distribution of workload through the resource on the cloud is a must for the enterprise level solution providing products for the workload automation market.
Here one should rise question; if it is possible to execute remote processes without agent, why should I prefer the with-agent solution that will bring more complexity and the remarkable rise in the cost ?
Here we should technically discuss the architecture and define the term agent and describe roles of the agents. Simply, an agent is an application that is deployed on any platform on the network and executes the orders provided by the host server via asynchronous communication and helps the server for job management feed the server with relevant reporting information produced during process execution lifecycle.
Actually, remote process execution without agent looks like simple but it contains important pitfalls.
Some of the parameters of the remote jobs should be defined carefully regarding environment of the execution platform that may mostly vary between different platforms. For example, if you are planning to execute a shell script remotely, possibly it will not behave on the remote platform similar to local as expected.
Second one of the restrictions is the requirement of 100% up & tuning network connection requirement during the job execution. Otherwise result or current status of the executing process cannot be retrieved under the circumstance of the loss of the network connection. Possibilities, it will continue to work or not, or be terminated successfully or fail and the controller program will never be informed until connection is up. If the long time jobs are the subject, the high risk should be realized.
In such conditions, it is a killing requirement to have 100% percent up & running network connection between the scheduler and remote platform that the job will be executed on.
Loosely-Coupled & Tightly-Coupled
At this point it should be slightly realized that this kind of solution cannot be named as distributed workload management. At most we can say remote job execution. From this point of view, TlosSW with agent, can manage the workload automation process and distribute load according to built-in intelligent workload distribution algorithms with fire & forget principle which is affected by the network faults on very low level.
With the information including TlosSW, another question that may come to mind; Is it possible for TlosLite to find a place on the market that is full of Enterprise Level Schedulers providing solution for the major companies?
The restrictions previously mentioned have the answer to this question actually. TlosLite, by its nature, does not overload its execution platform and can be deployed without any performance issues. Beside, as all the jobs are executed locally it is not necessary to make any configuration on jobs for TlosLite. We may add the cost advantage of multi-instance deployment compared to enterprise products.
After all, if it is required to execute jobs on more than one server, it is possible to install multiple instances of TlosLite to execute these jobs and manage these instances with MC- Management Console application centrally in one place without being effected or with minimal effect of the network failures. It is also possible to define dependencies between TlosLite instances if it is necessary.
With TlosLite, while executing jobs, it is not required to have high quality network for execution except for the cases that the job nature requires.
As a result, powerful scheduling products without agent cannot compete with TlosSW, also not even with TlosLite which is providing benefits of the ability of network-error-free operation systematic.
Therefore, when our products are compared with the competitors, our customers deciding not to prefer TlosLite are going to face the problems of not having distributed architecture that will result losing the reliability and stability.
Tlos Schedulers
Comments
Post a Comment